Badruzeus Posted March 10, 2019 Share Posted March 10, 2019 2 minutes ago, STLVNUB said: I'm using build_clover Have sucessfully built BaseTools but have this error build.py... /home/stlvnub/src/edk2/MdePkg/Library/BaseLib/BaseLib.inf(-1): error 3000: PCD [gEfiMdePkgTokenSpaceGuid.PcdControlFlowEnforcementPropertyMask] in [/home/stlvnub/src/edk2/MdePkg/Library/BaseLib/BaseLib.inf] is not found in dependent packages: /home/stlvnub/src/edk2/MdePkg/MdePkg.dec - Failed - Build end time: 21:28:46, Mar.10 2019 Build total time: 00:00:01 Will fix tomorrow, need some sleep. Even after changing this line? 1637 EDK2_REV="${EDK2_REV:-28976}" 1 Link to comment Share on other sites More sharing options...
Zenith432 Posted March 10, 2019 Share Posted March 10, 2019 Patches_for_EDK2 is synced up to git tag edk2-stable201903/svn r28976 which will remain stable for at least 3 months. Patches_for_UDK2018 works with git tag vUDK2018, and I believe also with branch UDK2018, although there's a commit there adding a file Lfence.nasm (7648fe3) that I have not synced to Clover so as not to break compatibility with vUDK2018. 3 Link to comment Share on other sites More sharing options...
STLVNUB Posted March 11, 2019 Share Posted March 11, 2019 fixed svn revision now this error [SLINK] GrubEXFAT /home/stlvnub/src/edk2/Clover/FileSystems/GrubFS/grub/grub-core/fs/hfsplus.c: In function 'list_nodes': /home/stlvnub/src/edk2/Clover/FileSystems/GrubFS/grub/grub-core/fs/hfsplus.c:714:57: error: taking address of packed member of 'struct grub_hfsplus_catkey' may result in an unaligned pointer value [-Werror=address-of-packed-member] 714 | *grub_utf16_to_utf8 ((grub_uint8_t *) filename, catkey->name, | ~~~~~~^~~~~~ /home/stlvnub/src/edk2/Clover/FileSystems/GrubFS/grub/grub-core/fs/hfsplus.c: In function 'grub_hfsplus_label': /home/stlvnub/src/edk2/Clover/FileSystems/GrubFS/grub/grub-core/fs/hfsplus.c:996:57: error: taking address of packed member of 'struct grub_hfsplus_catkey' may result in an unaligned pointer value [-Werror=address-of-packed-member] 996 | *grub_utf16_to_utf8 ((grub_uint8_t *) (*label), catkey->name, | ~~~~~~^~~~~~ cc1: all warnings being treated as errors make: *** [GNUmakefile:833: /home/stlvnub/src/edk2/Build/Clover/RELEASE_GCC53/X64/Clover/FileSystems/GrubFS/src/HFSPLUS/OUTPUT/grub/grub-core/fs/hfsplus.obj] Error 1 build.py... : error 7000: Failed to execute command make tbuild [/home/stlvnub/src/edk2/Build/Clover/RELEASE_GCC53/X64/Clover/FileSystems/GrubFS/src/HFSPLUS] build.py... : error F002: Failed to build module /home/stlvnub/src/edk2/Clover/FileSystems/GrubFS/src/HFSPLUS.inf [X64, GCC53, RELEASE] - Failed - Build end time: 15:25:48, Mar.11 2019 Build total time: 00:00:53 o_Ops, ./ebuild.sh exited with error(s), aborting.. Link to comment Share on other sites More sharing options...
Zenith432 Posted March 11, 2019 Share Posted March 11, 2019 @STLVNUB: There's something wrong with your local copy. I can build Clover r4898 from svn just fine with gcc 8.3, latest edk2 with Patches_for_EDK2 over it. Try doing clean build and rebuild the tools. 1 Link to comment Share on other sites More sharing options...
STLVNUB Posted March 11, 2019 Share Posted March 11, 2019 Sorry, building on Linux using GCC9.0.1 Experimental, probably why the error, maybe Link to comment Share on other sites More sharing options...
Badruzeus Posted March 11, 2019 Share Posted March 11, 2019 1 minute ago, STLVNUB said: Sorry, building on Linux using GCC9.0.1 Experimental, probably why the error, maybe Yeah, those should be warnings but gcc9 marked as errors. You may try adding this line? -Wno-address-of-packed-member as well with ../VBoxFsDxe/fsw_hfs.c Link to comment Share on other sites More sharing options...
STLVNUB Posted March 11, 2019 Share Posted March 11, 2019 Or -Wno-errorsSent from my iPhone 5S using Tapatalk 1 Link to comment Share on other sites More sharing options...
Badruzeus Posted March 11, 2019 Share Posted March 11, 2019 1 hour ago, STLVNUB said: Or -Wno-errors I was referring to this workarround: https://lists.ubuntu.com/archives/fwts-devel/2019-February/011183.html But one solved, another having diff. bunch of errors LoL. Seems stupid using unstable GCC hah haa, no issue with 8.3.0. Link to comment Share on other sites More sharing options...
apianti Posted March 11, 2019 Share Posted March 11, 2019 It's basically saying that it won't be able optimize the code properly because the address is not on a boundary of the type for which it wants an address. You can remove this error by using the macro provided by edk2 to get the address offset of a member. It's just a lot of work to do just to not get a warning (since the macro is just the forcing unoptimization) when you can disable the warning. I thought that the warning is disabled though, maybe it was renamed in the newest gcc? 1 Link to comment Share on other sites More sharing options...
Slice Posted March 12, 2019 Share Posted March 12, 2019 On 3/11/2019 at 8:25 AM, Badruzeus said: Yeah, those should be warnings but gcc9 marked as errors. You may try adding this line? -Wno-address-of-packed-member as well with ../VBoxFsDxe/fsw_hfs.c This warning should be cured by using function ReadUnaligned() else you get wrong result. Don't do no-warning or no-error if you don't want unpredictable result. 1 Link to comment Share on other sites More sharing options...
apianti Posted March 12, 2019 Share Posted March 12, 2019 No, the problem is not reading unaligned, as that is done in be32/64_to_cpu_ua(). The problem is taking the address of an unaligned member, the address-of operator (&) needs to be replaced to not be optimized by getting the address using (MEMBERTYPE *)(((UINT8 *)address) + OFFSET_OF(TYPE, member)). 1 Link to comment Share on other sites More sharing options...
STLVNUB Posted March 12, 2019 Share Posted March 12, 2019 On 3/11/2019 at 12:33 AM, Zenith432 said: Patches_for_EDK2 is synced up to git tag edk2-stable201903/svn r28976 which will remain stable for at least 3 months. Patches_for_UDK2018 works with git tag vUDK2018, and I believe also with branch UDK2018, although there's a commit there adding a file Lfence.nasm (7648fe3) that I have not synced to Clover so as not to break compatibility with vUDK2018. Wouldn't it be a lot easier and cleaner to adapt Clovers source code to EDK2/UDK2918 standards, this is like a dog chasing its tail. Link to comment Share on other sites More sharing options...
Badruzeus Posted March 13, 2019 Share Posted March 13, 2019 4 hours ago, STLVNUB said: Wouldn't it be a lot easier and cleaner to adapt Clovers source code to EDK2/UDK2918 standards, this is like a dog chasing its tail. Just updated to newer GCC 9.0.1 (20190311) on Ubuntu 19.04. The issue is still persist, nevermind. sudo apt-get update && sudo apt-get full-upgrade Link to comment Share on other sites More sharing options...
Badruzeus Posted March 13, 2019 Share Posted March 13, 2019 Well, I'm just bit curious: Using a same compiler why building Clover with Secure Boot produces more than twice binaries size? Anyway, which one is the right defined macros: -DENABLE_SECURE_BOOT or -D ENABLE_SECURE_BOOT (?) Thanks. Link to comment Share on other sites More sharing options...
STLVNUB Posted March 13, 2019 Share Posted March 13, 2019 I would use -DENABLE_SECURE_BOOT, reason being it is one parameter where -D ENABLE_SECURE_BOOT is two if calling from terminal You could put "-D ENABLE_SECURE_BOOT" which is one as well, they both do some thing of course 1 Link to comment Share on other sites More sharing options...
Badruzeus Posted March 13, 2019 Share Posted March 13, 2019 (edited) 28 minutes ago, STLVNUB said: I would use -DENABLE_SECURE_BOOT, reason being it is one parameter where -D ENABLE_SECURE_BOOT is two if calling from terminal You could put "-D ENABLE_SECURE_BOOT" which is one as well, they both do some thing of course OK, using -D ENABLE_SECURE_BOOT :: this is what I got: 0:100 0:000 Starting Clover revision: 4898 on American Megatrends EFI 0:100 0:000 Build with: [Args: --ext-co -D ENABLE_SECURE_BOOT | -D ENABLE_SECURE_BOOT -D USE_LOW_EBDA -D HAVE_LEGACY_EMURUNTIMEDXE -a X64 -b RELEASE -t GCC53 -n 2 | OS: Ubuntu 19.04] #EDIT: Wait @STLVNUB; it seems I'm unable using -DENABLE_SECURE_BOOT option. Edited March 13, 2019 by Badruzeus Link to comment Share on other sites More sharing options...
apianti Posted March 14, 2019 Share Posted March 14, 2019 It shouldn't matter, all three ways @STLVNUB gave should work, they are all valid arguments forms for edk build. However, the problem is probably the clover build script since it parses the command line and reforms the arguments to pass to edk build, so it may not check correctly for them. Just stick with whichever one works, it will build the secure boot support. You need to sign your binaries in order for them to work in secure boot, it's not automated... Or you can attempt to change the security policy to ask add the hash of the binaries to the whitelist when they are loaded the first time. The files are larger because they need secure boot support which means openssl support, which is huge. Link to comment Share on other sites More sharing options...
Power Mac Posted March 23, 2019 Share Posted March 23, 2019 (edited) Hi, I believe both No and Detect options for Inject Kexts are, once again, broken in Clover. While trying to improve my boot time, I took a look at my debug.log; I found out that, despite the fact that I've always used Detect (given that I place any extra kexts in Library/Extensions), Clover keeps loading kexts from the Other folder too. I then tried No instead of Detect, but the result is the same (with the exception that Clover skips kext injection... only to inject them just a line later). I can't track back the version that re-introduced the bug, but it's been the case for at least the current release and the previous one, and I'm sure there's nothing wrong with my configuration (my config.plist is quite spartan and I checked it out for possible conflicts). Besides, even if there were severe issues related to my kext cache (that Clover should read in order to detect FakeSMC), Inject Kexts=No should do its work in any given condition. Last but not least, RehabMan already found out such a bug in an older Clover version, that's why I believe the feature still needs some refinement. Here's a sample. To try and narrow down the issue, for this debug boot I deleted every kext in Other and set "No" for Inject Kexts. But as you can see, Clover keeps trying to inject kexts. When I actually leave some kexts in Other, they end up loading just fine (redundantly and pointlessly). skipping kext injection (not requested) 10:358 0:010 Use origin smbios table type 1 guid. 10:374 0:015 Preparing kexts injection for arch=x86_64 from EFI\CLOVER\kexts\Other 10:380 0:006 Extra kext: EFI\CLOVER\kexts\Other\WhateverGreen.kext (v.1.2.6) 10:389 0:008 Failed to load extra kext (Info.plist not found): EFI\CLOVER\kexts\Other\WhateverGreen.kext I hope this'll be useful. P.S. I haven't tried the current beta iteration yet (Clover 4901) because I prefer waiting for stable releases for the sake of safeness. Edited March 23, 2019 by Power Mac Link to comment Share on other sites More sharing options...
apianti Posted March 23, 2019 Share Posted March 23, 2019 It seems to break often. It's not a big deal, the extra ones are actually discarded if the kext identifier is already in the cache, there is no way to tell from the log if they were actually injected though as that just means they were prepared to be injected. Injection happens much later and can't be printed to the log only the screen. However, Lilu+Whatevergreen kexts should always be injected. You should actually inject kexts that are required to boot, and install other kexts that are only needed for extra functionality. Detection only disables injection if FakeSMC is in the cache, this is what you'd want as you want to not inject kexts already in the cache because you also installed them but you need to install FakeSMC for it to work. Link to comment Share on other sites More sharing options...
Power Mac Posted March 23, 2019 Share Posted March 23, 2019 1 hour ago, apianti said: It seems to break often. It's not a big deal, the extra ones are actually discarded if the kext identifier is already in the cache, there is no way to tell from the log if they were actually injected though as that just means they were prepared to be injected. Injection happens much later and can't be printed to the log only the screen. However, Lilu+Whatevergreen kexts should always be injected. You should actually inject kexts that are required to boot, and install other kexts that are only needed for extra functionality. Detection only disables injection if FakeSMC is in the cache, this is what you'd want as you want to not inject kexts already in the cache because you also installed them but you need to install FakeSMC for it to work. No, it's not a killer bug by any means, but I'd rather avoid injecting the same kexts twice and always having to make sure both locations are up-to-date. I didn't know that the log can't actually tell you whether the kext was injected or not: I assumed that was the case, given that with Detect it says something like "successfully loaded" for each kext, so thanks for the tip. I do not agree with your advice on injection, though (sorry if I misinterpreted your words): as stated by many, there's no reason not to install every kext in /L/E, given that injected kexts live outside of the protected MacOS memory space (and some kexts do not even work correctly when injected). For this reason, I keep as few kexts as possible in Other (the ones strictly needed to run the installer). I hope the bug can be fixed soon. Link to comment Share on other sites More sharing options...
apianti Posted March 23, 2019 Share Posted March 23, 2019 First, I did not say inject all of your kexts, I said inject the ones that are required for you to boot. If an extension doesn't work when injected its because it needs another kext that is not loaded, you can try to force loading those kexts. I don't know who told you the nonsense of the protected macOS memory space, that is not even a thing. The kexts are injected through a mechanism that is present in the kernel to load extensions from the boot loader, all kernel extensions are loaded into the kernel memory space or they couldn't work... There is reason to inject some kexts, as I said Lilu+Whatevergreen need to be injected to ensure they are initialized before any of the kexts they patch. 1 Link to comment Share on other sites More sharing options...
chris1111 Posted March 23, 2019 Share Posted March 23, 2019 9 hours ago, Power Mac said: Hi, I believe both No and Detect options for Inject Kexts are, once again, broken in Clover. While trying to improve my boot time, I took a look at my debug.log; I found out that, despite the fact that I've always used Detect (given that I place any extra kexts in Library/Extensions), Clover keeps loading kexts from the Other folder too. I then tried No instead of Detect, but the result is the same (with the exception that Clover skips kext injection... only to inject them just a line later). I can't track back the version that re-introduced the bug, but it's been the case for at least the current release and the previous one, and I'm sure there's nothing wrong with my configuration (my config.plist is quite spartan and I checked it out for possible conflicts). Besides, even if there were severe issues related to my kext cache (that Clover should read in order to detect FakeSMC), Inject Kexts=No should do its work in any given condition. Last but not least, RehabMan already found out such a bug in an older Clover version, that's why I believe the feature still needs some refinement. Here's a sample. To try and narrow down the issue, for this debug boot I deleted every kext in Other and set "No" for Inject Kexts. But as you can see, Clover keeps trying to inject kexts. When I actually leave some kexts in Other, they end up loading just fine (redundantly and pointlessly). skipping kext injection (not requested) 10:358 0:010 Use origin smbios table type 1 guid. 10:374 0:015 Preparing kexts injection for arch=x86_64 from EFI\CLOVER\kexts\Other 10:380 0:006 Extra kext: EFI\CLOVER\kexts\Other\WhateverGreen.kext (v.1.2.6) 10:389 0:008 Failed to load extra kext (Info.plist not found): EFI\CLOVER\kexts\Other\WhateverGreen.kext I hope this'll be useful. P.S. I haven't tried the current beta iteration yet (Clover 4901) because I prefer waiting for stable releases for the sake of safeness. Check the contents of your WhateverGreen.kext kext to see if it's like it should be Link to comment Share on other sites More sharing options...
Slice Posted March 24, 2019 Share Posted March 24, 2019 I am happy with existing injection algorithm (inject=YES) and a possibility to disable some kexts in Other folder by Clover GUI. 4 Link to comment Share on other sites More sharing options...
Power Mac Posted March 24, 2019 Share Posted March 24, 2019 (edited) 14 hours ago, chris1111 said: Check the contents of your WhateverGreen.kext kext to see if it's like it should be Thank you for the suggestion but that's not the issue there: the log returns that error because I emptied my Other folder for that test (that is, WhateverGreen wasn't physically there anymore); it loads just fine, with the other ones, if I leave them in Other. 14 hours ago, apianti said: First, I did not say inject all of your kexts, I said inject the ones that are required for you to boot. If an extension doesn't work when injected its because it needs another kext that is not loaded, you can try to force loading those kexts. I don't know who told you the nonsense of the protected macOS memory space, that is not even a thing. The kexts are injected through a mechanism that is present in the kernel to load extensions from the boot loader, all kernel extensions are loaded into the kernel memory space or they couldn't work... There is reason to inject some kexts, as I said Lilu+Whatevergreen need to be injected to ensure they are initialized before any of the kexts they patch. Well, the "one" who told me, corroborated by a couple other devs, is a guide on the site of the one who shall not be named (but is active in the developers' corner): can't link anything because I don't want a ban, but I trust him deeply, and most of the times his guides and advice are a step ahead of everyone else's. Anyway, adding what Slice said to the mix, if I were in your shoes I'd either remove the functionality or fix it: it's going to be confusing for new users who won't be able to wrap their head around it, and old ones like me will keep believing it's a forgotten bug. Besides, if what has been said about injecting kexts is true, is there a master list of kexts that need injection and kext who do not? Because GitHub pages never mention anything of the sort. Edited March 24, 2019 by Power Mac Link to comment Share on other sites More sharing options...
apianti Posted March 24, 2019 Share Posted March 24, 2019 Literally every single one of them is wrong then. There is no possible other place for the extensions to be loaded except into the kernel memory space. Especially since there is only kernel and user memory spaces, kernel extensions don't really make much sense outside of the kernel.... Inject kexts that you need to boot successfully, any kext that needs to be initialized first before another kext and perform some action on that kext, needs to be injected since boot loader kernel extensions are initialized first. I don't really have time to deal with any issues currently and if slice says it's working right then, idk. Link to comment Share on other sites More sharing options...
Recommended Posts