Ensure DevicePath is FilePath Prior to Accessing PathName (#292)

If the Shell logic attempts to locate the startup.nsh script on a drive
other than FS0:, it will check the device path of the shell which does not
work correctly for the internal shell because the shell file path is located
in the firmware volume. To ensure we don't try to read an invalid filepath
string, check the type and subtype of the device path header to ensure it
is a filepath device type.

This bug causes a crash on SBSA when guard pages are active because
startup.nsh is located in the virtual drive mapped to FS2:.

- [x] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware
functions?
- Examples: Add a new library, publish a new PPI, update an algorithm,
...
- [ ] Impacts security?
- **Security** - Does the change have a direct security impact on an
application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- [ ] Breaking change?
- **Breaking change** - Will anyone consuming this change experience a
break
    in build or boot behavior?
- Examples: Add a new library class, move a module to a different repo,
call
    a function in a new library class in a pre-existing module, ...
- [ ] Includes tests?
  - **Tests** - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- [ ] Includes documentation?
- **Documentation** - Does the change contain explicit documentation
additions
    outside direct code modifications (and comments)?
- Examples: Update readme file, add feature readme file, link to
documentation
    on an a separate Web page, ...

Booting on Q35 and SBSA

N/A

Bugfix: Update device path type check when searching for startup.nsh (#300)

Fixes #298

PR #292 had the incorrect Type for a Filepath Device Path.

- [x] Impacts functionality?
  - **Functionality** - Does the change ultimately impact how firmware functions?
  - Examples: Add a new library, publish a new PPI, update an algorithm, ...
- [ ] Impacts security?
  - **Security** - Does the change have a direct security impact on an application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- [ ] Breaking change?
  - **Breaking change** - Will anyone consuming this change experience a break
    in build or boot behavior?
  - Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
- [ ] Includes tests?
  - **Tests** - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- [ ] Includes documentation?
  - **Documentation** - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  - Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...

N/A

N/A

ShellPkg/Application/Shell/Shell.c

@@ -1260,9 +1260,15 @@ LocateStartupScript (
     }
 
     InternalEfiShellSetEnv (L"homefilesystem", StartupScriptPath, TRUE);
+    // MU_CHANGE START: Ensure FileDevicePath is a FILEPATH_DEVICE_PATH prior to accessing PathName
+    if ((FileDevicePath->Type == MEDIA_DEVICE_PATH) && (FileDevicePath->SubType == MEDIA_FILEPATH_DP)) {
+      StartupScriptPath = StrnCatGrow (&StartupScriptPath, &Size, ((FILEPATH_DEVICE_PATH *)FileDevicePath)->PathName, 0);
+      PathRemoveLastItem (StartupScriptPath);
+    } else {
+      StartupScriptPath = StrnCatGrow (&StartupScriptPath, &Size, L"\\", 0);
+    }
 
-    StartupScriptPath = StrnCatGrow (&StartupScriptPath, &Size, ((FILEPATH_DEVICE_PATH *)FileDevicePath)->PathName, 0);
-    PathRemoveLastItem (StartupScriptPath);
+    // MU_CHANGE END
     StartupScriptPath = StrnCatGrow (&StartupScriptPath, &Size, mStartupScript, 0);
   }