Device/PhysicalMemory Object
Device/PhysicalMemory Object
What does /Device/PhysicalMemory Object do?
The /Device/PhysicalMemory section object is used by some applications to access physical memory. Common examples of this use are management applications that attempt to read System Management BIOS (SMBIOS) or other BIOS data that is stored in the lowest 1 MB of physical memory.
Who does this feature apply to?
This feature will be of interest to hardware and hardware management application developers.
What existing functionality is changing in Windows Server 2003 Service Pack 1?
Device/PhysicalMemory section object
Detailed description
In Windows Server 2003 SP1, user-mode access to the /Device/PhysicalMemory object is not permitted. All forms of access (read, write) are refused when the /Device/PhysicalMemory object is accessed from a user-mode application. Access to the /Device/PhysicalMemory object is refused regardless of the user context (Administrators, Users, Local System, etc.) the application is running in.
Kernel-mode (driver) access to the /Device/PhysicalMemory object is unchanged for Windows Server 2003 SP1.
There are no means to revert this changed behavior in Windows Server 2003 SP1.
Why is this change important? What threats does it help mitigate?
This change was made to help prevent security exploits that might leverage the functionality of the /Device/PhysicalMemory object from user-mode.
In previous versions of Windows, access to the /Device/PhsyicalMemory object was protected by an access control list (ACL). However, the ACL may be inadvertently changed. Refusing all access to the /Device/PhysicalMemory object from user-mode ensures this scenario cannot occur.
What works differently? Are there any dependencies?
While the majority of applications do not attempt to access physical memory, some management applications that require information from the BIOS may be affected by this change. Many of these management applications may be attempting to read SMBIOS data.
How do I fix these issues?
Management application vendors are encouraged to review their applications for access to the /Device/PhysicalMemory object and implement one of the workarounds proposed in this section.
Note:
The following methods can be used to read low physical memory and firmware table data from an application in Windows Server 2003 SP1. Applications that require write access to low physical memory must do so from a kernel-mode driver.
Reading SMBIOS information
Windows Management Instrumentation (WMI) is the preferred method for reading SMBIOS information in Windows. WMI supports reading individual SMBIOS properties (such as the BIOS version or the system manufacturer) from the Win32 classes contained in the root/cimv2 namespace.
WMI also supports reading the entire contents of SMBIOS data in a single buffer using the MSSMBios_RawSMBiosTables class inside of the root/wmi namespace. The SMBiosData property returns a buffer containing the entire SMBIOS data table, except the SMBIOS Structure Table Entry Point as defined in section 2.1.1 of the SMBIOS specification.
WMI supports both a COM and script API to access WMI information. Additionally, WMI is supported in the Windows XP SP2 and Windows Server 2003 SP1 versions of the Windows Preinstallation Environment (WinPE).
Do I need to change my code to work with Windows Server 2003 Service Pack 1?
If your application uses the /Device/PhysicalMemory object you will need to change your code for your application to work with Windows Server 2003 SP1. There are two new user-mode APIs that can be used by applications to read various system firmware tables. These APIs can be used to read SMBIOS and ACPI data, as well as raw BIOS data from low physical memory. The details of the API implementation are available in the Platform SDK at the MSDN Web site. The following are the two new APIs:
• EnumSystemFirmwareTables, described on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=45562.
• GetSystemFirmwareTable, described on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=45563.
For more information
The following Web resources may also be of interest to you if you are affected by this change in functionality:
• The Windows Management Instrumentation (WMI) section of the Windows Platform SDK available on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=159.
• The System Management BIOS (SMBIOS) standard specification provide by the Distributed Management Task Force, Inc. (DMTF) which is available on the DMTF Web site at http://go.microsoft.com/fwlink/?LinkId=38721.
• The Microsoft® Windows® Preinstallation Environment (Windows PE) tool, which is available for download on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=38722.
What does /Device/PhysicalMemory Object do?
The /Device/PhysicalMemory section object is used by some applications to access physical memory. Common examples of this use are management applications that attempt to read System Management BIOS (SMBIOS) or other BIOS data that is stored in the lowest 1 MB of physical memory.
Who does this feature apply to?
This feature will be of interest to hardware and hardware management application developers.
What existing functionality is changing in Windows Server 2003 Service Pack 1?
Device/PhysicalMemory section object
Detailed description
In Windows Server 2003 SP1, user-mode access to the /Device/PhysicalMemory object is not permitted. All forms of access (read, write) are refused when the /Device/PhysicalMemory object is accessed from a user-mode application. Access to the /Device/PhysicalMemory object is refused regardless of the user context (Administrators, Users, Local System, etc.) the application is running in.
Kernel-mode (driver) access to the /Device/PhysicalMemory object is unchanged for Windows Server 2003 SP1.
There are no means to revert this changed behavior in Windows Server 2003 SP1.
Why is this change important? What threats does it help mitigate?
This change was made to help prevent security exploits that might leverage the functionality of the /Device/PhysicalMemory object from user-mode.
In previous versions of Windows, access to the /Device/PhsyicalMemory object was protected by an access control list (ACL). However, the ACL may be inadvertently changed. Refusing all access to the /Device/PhysicalMemory object from user-mode ensures this scenario cannot occur.
What works differently? Are there any dependencies?
While the majority of applications do not attempt to access physical memory, some management applications that require information from the BIOS may be affected by this change. Many of these management applications may be attempting to read SMBIOS data.
How do I fix these issues?
Management application vendors are encouraged to review their applications for access to the /Device/PhysicalMemory object and implement one of the workarounds proposed in this section.
Note:
The following methods can be used to read low physical memory and firmware table data from an application in Windows Server 2003 SP1. Applications that require write access to low physical memory must do so from a kernel-mode driver.
Reading SMBIOS information
Windows Management Instrumentation (WMI) is the preferred method for reading SMBIOS information in Windows. WMI supports reading individual SMBIOS properties (such as the BIOS version or the system manufacturer) from the Win32 classes contained in the root/cimv2 namespace.
WMI also supports reading the entire contents of SMBIOS data in a single buffer using the MSSMBios_RawSMBiosTables class inside of the root/wmi namespace. The SMBiosData property returns a buffer containing the entire SMBIOS data table, except the SMBIOS Structure Table Entry Point as defined in section 2.1.1 of the SMBIOS specification.
WMI supports both a COM and script API to access WMI information. Additionally, WMI is supported in the Windows XP SP2 and Windows Server 2003 SP1 versions of the Windows Preinstallation Environment (WinPE).
Do I need to change my code to work with Windows Server 2003 Service Pack 1?
If your application uses the /Device/PhysicalMemory object you will need to change your code for your application to work with Windows Server 2003 SP1. There are two new user-mode APIs that can be used by applications to read various system firmware tables. These APIs can be used to read SMBIOS and ACPI data, as well as raw BIOS data from low physical memory. The details of the API implementation are available in the Platform SDK at the MSDN Web site. The following are the two new APIs:
• EnumSystemFirmwareTables, described on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=45562.
• GetSystemFirmwareTable, described on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=45563.
For more information
The following Web resources may also be of interest to you if you are affected by this change in functionality:
• The Windows Management Instrumentation (WMI) section of the Windows Platform SDK available on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=159.
• The System Management BIOS (SMBIOS) standard specification provide by the Distributed Management Task Force, Inc. (DMTF) which is available on the DMTF Web site at http://go.microsoft.com/fwlink/?LinkId=38721.
• The Microsoft® Windows® Preinstallation Environment (Windows PE) tool, which is available for download on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=38722.