Remember hex type to support MBR creation.

Before this patch, requesting a code like "0x0c00" would be flattened
to "0x0700" because it was translated through the GUID type table.

Callers creating MBR tables expect these codes to flow through without
this fidelity loss.  To support this, we stash away any provided hex
type and return it instead of doing a lookup.

Test: cts-tradefed run commandAndExit cts-dev --abi armeabi-v7a -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.AdoptableHostTest
Bug: 63735902
Change-Id: If61407960c9ad1050e5f9031617d71d68f7820b4
This commit is contained in:
Jeff Sharkey
2017-10-19 13:27:21 -06:00
parent 696d5fd62a
commit d6f72efe5d
2 changed files with 12 additions and 0 deletions

View File

@@ -364,6 +364,8 @@ int GPTDataCL::DoOptions(int argc, char* argv[]) {
if (partNum < 0)
partNum = newPartNum;
if ((partNum >= 0) && (partNum < (int) GetNumParts())) {
// Remember the original hex value requested
typeRaw[partNum] = GetString(typeCode, 2);
typeHelper = GetString(typeCode, 2);
if ((typeHelper != (GUIDData) "00000000-0000-0000-0000-000000000000") &&
(ChangePartType(partNum, typeHelper))) {
@@ -494,6 +496,14 @@ int GPTDataCL::BuildMBR(char* argument, int isHybrid) {
operator[](origPartNum).GetLengthLBA());
newPart.SetStatus(0);
newPart.SetType((uint8_t)(operator[](origPartNum).GetHexType() / 0x0100));
// If we were created with a specific hex type, use that instead
// of risking fidelity loss by doing a GUID-based lookup
if (typeRaw.count(origPartNum) == 1) {
string raw = typeRaw[origPartNum];
if (raw.size() == 4) {
newPart.SetType(StrToHex(raw, 0));
}
}
newMBR.AddPart(i + isHybrid, newPart);
} else {
cerr << "Original partition " << origPartNum + 1 << " does not exist or is too big! Aborting operation!\n";