VMware Communities
chuckrenner
Contributor
Contributor

EFI Shell inconsistent behavior with internal mm command

Hi.

I have a Mac OS X 10.8 (Mountain Lion) guest.

I have set the "EFI Shell (unsupported)" as my first boot device.

On the guest's hard drive, there is a "startup.nsh" script.  Here's a snippet that is using the mm command to write to some physical memory addresses in the guest:

mm 7ffa80b0 0000000000000000 -w 8 -MEM -n

mm 7ffa80b0 00000000 -w 4 -MEM -n

mm 7ffa80b0 0000 -w 2 -MEM -n

mm 7ffa80b0 00 -w 1 -MEM -n

mm 7ffa80b0 00 -MEM -n

mm 7ffa80b0 00 -n

mm 7ffa80b0 00

MM 7FFA80B0 00

mm     7ffa80b0     00

MM     7FFA80B0     00

mm 0000000077ffa80b0 00

MM 0000000077FFA80B0 00

All of these commands have three things in common:

  1. They work if manually typed in the EFI Shell.
  2. They DO NOT work when called from a script like "startup.nsh" or with the "startup" command in the EFI shell.
  3. They all are supposed to write one or more null (0x00) bytes to physical memory in the guest OS, starting at address 0x000000007FFA80B0 (they do exactly that if typed in the EFI Shell manually, but don't work if called from a script/batch file.

Why, oh why, does it work if typed manually in the shell, but not if called from a script/batch file? I thought that "mm" might be an application/image running from a different folder/path when called from a script/batch file, but this is not the case, as mm is an internal EFI Shell command (and not an application/image).

Anybody got any other suggestions for pulling this off?

0 Kudos
4 Replies
vanRijn
Hot Shot
Hot Shot

Interesting question. I'll forward it on internally to someone who might be able to answer. =:)

0 Kudos
HPReg
VMware Employee
VMware Employee

chuckrenner,

I'm thinking maybe the VMware EFI Shell simply does not honor the startup.nsh script?

If you place other commands than mm in startup.nsh, do they get executed and do they work?

Out of curiosity, what is at address 7ffa80b0 in that VM right after booting?

0 Kudos
chuckrenner
Contributor
Contributor

It executes every line of startup.nsh. I'm currently using echo commands to show me the mm commands to type once the shell is loaded.

If I attempt to write to memory with mm from a nsh script, mm will fail with an error message about wrong word width or invalid parameters. This happens both when run automatically from startup.nsh and when called from the EFI shell.

But the exact same mm commands work when run individually from the shell prompt. In other words, mm will write to memory when manually typed, but not when called from a nsh script.

I'm not near the VM right now, but the memory I'm altering is some of the vendor strings found in the SMBIOS (for guest software compatibility).

The documentation on SMBIOS formats, memory, and offsets is pretty easy to find, but the only time that I can write to those memory addresses is before an OS is loaded.

The ideal script would find the paragraph aligned SMBIOS anchor, read the locations of its table and structures, write the required bytes at the appropriate locations, and finally instruct the VM to boot from a specific drive.

But, without scriptable memory writes, there's no point in figuring out the rest.

It's probably easier to patch the EFI shell from the host!

--

Chuck Renner

Sent from my Galaxy Nexus (Android phone)

0 Kudos
graskind
Contributor
Contributor

Quite by accident, I ran across this same problem, and a LOT of Googling randomly had me stumble across a solution from this link:

http://forums.macrumors.com/showpost.php?p=14087907&postcount=225

I have no idea where this syntax difference is documented, what it means, how it works, or why, but it did work for me. I hope it's useful to you as well. I would love to know if anyone can explain why the EFI Shell (or at least certain versions of it) have this ridiculous, seemingly undocumented quirk.

-- Gwynne Raskind

0 Kudos