This question is a followup to the question I posted here:
As I mentioned in the other question I am running Ubuntu 18.04 on an HP g5 Laptop and have run the sample programs found in the SDK. By running the sample program found here:
I have determined that I have 93.5 MB reserved for the Enclaves and this memory cannot be touched by other processes. Is there a way to reduce this memory? For example, I might be interested in using only 32 MB. I have seen information saying that it is possible to reduce this memory region by a setting in the BIOS. However, I see only options for Enable, Disable and Software Controlled. The BIOS is from Insyde. I updated to the latest version hoping that it would give me an option for adjusting the PRM but wihtout success. Any information on how I could go about reducing the memory reserved?
The laptop I am using is dual boot with Windows 10. Could Windows provide an option for adjusting the Processor Reserved Memory?
Any help is greatly appreciated,
- General Support
Good morning Will, I hope your weekend is going well.
I was going to reply to your other note but Jesus from Intel beat me to it.
I'm surprised that your platform would not have an option to set the amount of Processor Reserved Memory (PRM). We have been through a lot of SGX capable hardware and I can't remember seeing a platform that doesn't allow this value to be adjusted. It is common to see three configuration options of 128, 64 and 32 megabytes of memory.
I'm assuming you exhaustively searched through all of the BIOS configuration? MSI, for instance, tends to do a fairly good job of hiding the configuration options.
Perhaps Intel could enlighten us differently, but if the BIOS manufacturer has declined to surface the PRM aperture as a configuration option, there is little that can be done at the operating system level to effect this value. I believe the PRM is programmed via the Machine Specific Registers (MSR's) before the BIOS issues the command necessary to lock any further changes in the hardware configuration of the platform.
In fact, it would be contrary to the SGX security model to allow that capability, since it would result in an operational defect in the predicate that SGX implements a hardware root of trust, i.e. security in the face of an IAGO threat model of an adversary taking over the system software and/or a hypervisor implementation.
I'm assuming your interest in reducing the PRM aperture is to reduce the Merkle Tree height of the integrity tree maintained by the Memory Encryption Engine (MEE) in order to increase enclave memory performance? Otherwise there is little value in modifying the PRM value, as 100 megabytes or so on modern platforms is largely lost in the noise.
For those reading along at home. In addition to confidentiality protections the Memory Encryption Engine (MEE) implements memory integrity protections through the use of a Merkle Tree which has the root stored in processor SRAM memory. The MEE hardware also implements replay protections which are not strictly relevant to this discussion.
There are clearly defined and measurable latency costs associated with maintaining the integrity tree, hence I'm assuming, the rationale for making the PRM aperture a configurable option. Unfortunately, given the reality of mitigating speculative execution vulnerabilities in enclaves, the integrity tree maintenance costs may be the least of the performance concerns on the table. This is particularly true if one wants full security mitigations against Load Value Injection (LVI) which requires the insertion of a fencing instruction after each memory load which essentially has the effect of disabling speculative execution.
For completeness in all of this. The upcoming Ice Lake platform represents, arguably, the largest changes in SGX. In addition to significantly increased PRM sizes the platform, to my understanding, also has the option of disabling memory integrity protections. This is a nod to the performance problems inherent in maintaining the tall Merkle Tree's needed to support large expanses of enclave page cache memory.
It is also, unfortunately, a nod to the fact that security plays second fiddle to economics. A somewhat interesting tension for the whole premise of the Confidential Computing Consortium.
I hope all of this information is useful. As painful as contacting vendor support tends to be, it may be that HP could provide affirmative evidence on whether or not the PRM aperture size is configurable.
However, given the engineering realities involved, changing the value may have little or no operational value.
Have a good remainder of the weekend.
It is up to the BIOS manufacturer to expose the PRM setting - some do, and others don't - and this can change even within product lines. I have a PC whose BIOS allows me to change the PRM size and another PC (an HP) that does not allow it. You cannot set the size in software, either in Windows or in Linux; only BIOS can set the size.