Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't mount encrypted partition when LTO is enabled #164

Open
hadess opened this issue Apr 6, 2022 · 3 comments
Open

Can't mount encrypted partition when LTO is enabled #164

hadess opened this issue Apr 6, 2022 · 3 comments
Assignees

Comments

@hadess
Copy link

hadess commented Apr 6, 2022

Originally reported as https://bugzilla.redhat.com/show_bug.cgi?id=1950208

Using the current git HEAD version (ee71aa5)

$ sudo apfs-fuse /dev/sdd2 /mnt -d 31
Device /dev/sdd2 opened. Size is 16000000000
Mounting xid different from NXSB at 0 (xid = 36). xid = 36
Mounting xid 36
omap: oid=1027 xid=36 flags=0 size=0 paddr=1027
omap: oid=1028 xid=36 flags=0 size=0 paddr=1028
starting LoadKeybag @ 20003
Initialization of KeyManager failed.
Unable to load container.

This seems to be caused by Fedora enabling LTO by default in its builds:
https://fedoraproject.org/wiki/LTOByDefault

Building with LTO generate quite a few new warnings compared to without LTO, including a fair bunch of signedness issues, which are probably symptoms of places that LTO will eventually modify and thus break.

@sgan81
Copy link
Owner

sgan81 commented Jan 4, 2023

Stupid aliasing rules ... anyway, it should be fixed now, at the expense of encryption speed ...

@sgan81 sgan81 self-assigned this Jan 4, 2023
@sgan81
Copy link
Owner

sgan81 commented Jan 5, 2023

So, after a few more tests, I found the following:

  • The original code works if -flto is specified alongside with -fno-strict-alias
  • LTO with clang works fine

Apparently, the reason was that I had done some pointer casting in aes.Encrypt and aes.Decrypt (void * to uint32_t *) in order to speed up things. GCC was of the opinion though that aes.Encrypt/Decrypt did not write anything, and that the uint32_t * did not alias the void *, and therefore the whole call to aes.Decrypt could be optimized out ...

So I don't really know what's better ... having somewhat slower code, or using -fno-strict-alias when compiling with GCC and LTO ...

@RJVB
Copy link

RJVB commented Jan 5, 2023 via email

megari added a commit to megari/apfs-fuse that referenced this issue Jan 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants