Skip to content

Commit

Permalink
Encryption: try wrapped key also for device without metadata support
Browse files Browse the repository at this point in the history 
Change-Id: I8b58e45ec0d42470226083e8003dcd8152a91af1
  • Loading branch information
@mauronofrio
mauronofrio committed Nov 23, 2019
1 parent 8c0bcc8 commit 9bf7335
Showing 1 changed file with 8 additions and 1 deletion.
9 changes: 8 additions & 1 deletion partition.cpp
View file
Original file line number Diff line number Diff line change
Expand Up @@ -662,7 +662,14 @@ void TWPartition::Setup_Data_Partition(bool Display_Error) {
LOGERR("Primary block device '%s' for mount point '%s' is not present!\n", Primary_Block_Device.c_str(), Mount_Point.c_str());
}
} else {
Decrypt_FBE_DE();

if (!Decrypt_FBE_DE()) {
LOGINFO("Trying wrapped key.\n");
property_set("fbe.data.wrappedkey", "true");
if (!Decrypt_FBE_DE()) {
LOGERR("Unable to decrypt FBE device\n");
}
}
}
if (datamedia && (!Is_Encrypted || (Is_Encrypted && Is_Decrypted))) {
Setup_Data_Media();
Expand Down

8 comments on commit 9bf7335

@JarlPenguin
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This commit causes an error in TWRP even when /data decrypts successfully on an FDE device. Overriding the prop in the device tree doesn't help either.

@mauronofrio
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which error?

@DarthJabba9
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the device is not encrypted, you get the "Unable to decrypt FBE device" error message.

@mauronofrio
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, but it's not a problem, it's just an error that people without an ecrypted device will get, maybe we can pass it from error to info, so it will be readable in recovery.log but not in the device log

@DarthJabba9
Copy link

@DarthJabba9 DarthJabba9 commented on 9bf7335 Dec 3, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that would do the job - assuming that the issue is that the device is not encrypted, rather than the case of an encrypted device for which decryption attempts have failed.

@mauronofrio
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the decryption fails the user will get a lot of more errors (first of all /data mount error). This is the commit i thought:
https://gerrit.omnirom.org/#/c/android_bootable_recovery/+/36234/

@DarthJabba9
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that commit will be quite fine.

@JarlPenguin
Copy link

@JarlPenguin JarlPenguin commented on 9bf7335 Dec 4, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the decryption fails the user will get a lot of more errors (first of all /data mount error). This is the commit i thought:
https://gerrit.omnirom.org/#/c/android_bootable_recovery/+/36234/

This works. Thanks.

Please sign in to comment.