feat: Remote Platform Erase capability#2407
Conversation
a1f3953 to
16567d2
Compare
86f6395 to
4f898d2
Compare
15e3a49 to
b99abac
Compare
… is done in off state
| amtRouter.post('/features/:guid', amtFeaturesValidator(), validateMiddleware, ciraMiddleware, setAMTFeatures) | ||
| amtRouter.get('/boot/capabilities/:guid', ciraMiddleware, getBootCapabilities) | ||
| amtRouter.post('/boot/rpe/:guid', ciraMiddleware, setRPE) | ||
| amtRouter.post('/rpe/:guid', ciraMiddleware, sendRPE) |
There was a problem hiding this comment.
Do we need them POST /boot/rpe/:guid and POST /rpe/:guid ? I don't see UI calling them.
If that's true, please update the swagger doc's as well
| throw new MPSValidationError('CSME unconfigure cannot be combined with other erase operations', 400) | ||
| } | ||
|
|
||
| await req.deviceAction.sendRPE(mask, powerType) |
There was a problem hiding this comment.
It looks like powerType is accepted from the request and passed into sendRPE(), but it is never used. The method always computes the action from the device’s current power state instead.
This means a caller can send a specific powerType, receive 200 success, and still have that value silently ignored.
Could we either honor the supplied value or remove it from the route?
| // Step 5: Power Cycle Off Hard — S5→S0 required; warm reset keeps ME power rails active | ||
| const powerStateResult = await this.getPowerState() | ||
| const currentState = powerStateResult?.PullResponse?.Items?.CIM_AssociatedPowerManagementService?.PowerState | ||
| const action = currentState === '8' ? 2 : 5 |
There was a problem hiding this comment.
It looks like MPS only treats power state 8 as off:
currentState === '8' ? 2 : 5
However, CIM defines 6, 8, 12, and 13 as valid off states. Console’s rpe.go already uses isOffPowerState to cover all four, while MPS checks only 8.
Could we align MPS with Console and check all four off states?
2 participants
NOTE: Needs to be tested on real HW. Currently don't have an AMT 16+ device that supports RPE.
PR Checklist
What are you changing?
Adds Remote Platform Erase (RPE) support to MPS.
GET /amt/boot/capabilities/:guidendpoint returning rawAMT_BootCapabilitiesfor use by RPE and boot feature flowsPOST /amt/boot/rpe/:guidendpoint to enable/disable RPE on a device (setRPEEnabled)POST /amt/remoteErase/:guidendpoint to trigger a remote platform erase with a caller-supplied bitmask (sendRemoteErase)DeviceActionadditions:setRPEEnabled,sendRemoteErase,getBootCapabilitiessendRemoteErasehandles both hardware erase targets (via UEFI TLV boot parameters) and CSME/ConfigurationDataReset via theAMT_BootSettingDataPUTPlatformErase) before proceeding, returning a400if unsupportedsendRemoteEraserejecting anyeraseMaskthat combines the CSME unconfigure bit (0x10000) with hardware erase bits — returns400with a clear error messagegetPowerCapabilitiesintogetBootCapabilitiesto eliminate duplicate logicgetAMTFeatures/setAMTFeaturesto include RPE-related feature fieldsAnything the reviewer should know when reviewing this PR?
sendRemoteEraseimplementation follows the AMT spec sequence: GET boot settings → validate RPE enabled → switch boot service to RPE mode (32770) → PUT boot data with erase fields →SetBootConfigRole→ power cycle off-hard (action 5). A warm reset is insufficient; S5→S0 is required for the ME to act on the erase.0x10000bit ineraseMaskis a sentinel for CSME/ConfigurationDataReset— it is not a hardware TLV target and is stripped before building the UEFI parameter array.PlatformErasecapability field is not present on older firmware.