Post by josephreynolds1 on Dec 4, 2020 19:26:05 GMT
Is my understanding of Redfish's direction correct?: Per redfishforum.com/thread/393/modify-schema-propertys-permission - I understand the boundary of the Redfish spec is that various Assembly BinaryDataURI's identify the locations of EEPROMs that may contain serial numbers, permanent MAC addresses, etc., that relate to other parts of the Redfish spec. - Redfish is intended for end-users , so it does not specify the content of EEPROMs or allow updates. - Redfish acknowledges that manufacturers may need to write to the EEPROMs, and that is outside the scope of the Redfish spec.
I would like my Redfish implementation (https://github.com/openbmc/bmcweb) to allow a manufacturer to write the EEPROM. So I propose a new OemOpenBMCPerformService privilege. Specifically, this privilege is required to write to the EEPROM (PUT to the URI given by the BinaryDataURI property). The service agent would have this privilege; other accounts (possibly including administrator accounts) would omit this privilege, meaning they cannot write to the EEPROMs. I believe this is a straightforward customization to the Redfish authorization model. The name "PerformService" reflects the actions that a manufacturer's authorized service representative might have to do after replacing a FRU part, for example, setting the system serial number or MAC address back to its intended value.
My purpose for this thread is to document that Redfish does not intend to standardize this use case and to collect ideas about how to proceed.
Yes, both the mechanisms and the policies around updating EEPROMs are highly varied among device implementations. We created the "BinaryDataURI" property in the Assembly resource to provide a standard method to extract EEPROM contents (or any other configuration memory / structure). While a fairly rare service event, there are times that vendors want to view that data, and they were typically using "raw IPMI commands" and IPMItool to perform that task. By providing that functionality via Redfish, we hopefully removed a need to keep IPMItool around, and also made the request much easier to perform without requiring machine-specific instructions.
Now, beyond that, there are certainly times that vendors desire an ability to change the contents of those EEPROMs. From a Redfish perspective, if that is a user-settable value, it would be exposed by a read-write Redfish property (the fact that the value is stored in an EEPROM is a behind-the-scenes detail). But for other "internal" data, it is certainly useful to provide a mechanism to change those contents in the field. And so one possibility is to allow a PUT/PATCH operation on the BinaryDataURI location that performs the update, much like a "raw IPMI command" would do. But that should be a protected operation, enabled/disabled through other means to prevent usage except in those rare service use cases. Which is exactly what you're recommending, and that would be my advice as well.