[Code] Support Conditional/Atomic HTTP operations to secure BIOS

[nicklela]

http://redfish.dmtf.org/schemas/DSP0266_1.6.1.html

6.1.5. ETags In order to reduce the cases of unnecessary RESTful accesses to resources, the Redfish Service should support associating a separate ETag with each resource.

Implementations should support returning ETag properties for each resource. Implementations should support returning ETag headers for each response that represents a single resource. Implementations shall support returning ETag headers for GET requests of ManagerAccount resources. The ETag is generated and provided as part of the resource payload because the service is in the best position to know if the new version of the object is different enough to be considered substantial. There are two types of ETags: weak and strong. If an ETag is supported for a given resource, it shall use the strong ETag format as specified in RFC7232.

This specification does not mandate a particular algorithm for creating the ETag, but ETags should be highly collision-free. An ETag could be a hash, a generation ID, a time stamp or some other value that changes when the underlying object changes.

If a client PUTs or PATCHes a resource, it should include an ETag in the HTTP If-Match/If-None-Match header from a previous GET. If a service supports returning the ETag header on a resource, the service may respond with status code 428 if the If-Match/If-None-Match header is missing from the PUT/PATCH request for the same resource, as specified in RFC6585.

In addition to returning the ETag property on each resource,

A Redfish Service should return the ETag header on client PUT/POST/PATCH A Redfish Service should return the ETag header on a GET of an individual resource The format of the ETag header is:

[nicklela]

This is the design to make sure that BIOS always use latest context

[nicklela]

Enhancement:

• use if-non-match to check resource modification instead of comparing ETag.

Note: OpenBMC has no ETag implementation: https://lore.kernel.org/all/6fd6fe09-7fb9-43c7-591b-fee5ed94c20c@linux.vnet.ibm.com/T/

We previously supported etag for static resources, hence the

references to them. They were removed when I moved phosphor-webui to webpack builds, and it was always on my list to add them back, using webpacks hashing mechanisms, but I never got a chance.

In practice, they didn't provide that much utility because most browsers:

1. only cache if you have a valid SSL certificate.
2. Have a very limited cache size.
3. Don't support cross site etag caches.

So in practice, the cache didn't provide any benefit in a majority of cases.

In terms of supporting etags on non-static resources, that's quite complex, given that cache invalidation is difficult, and likely deserves its own design document.

[nicklela]

Another solution is on BMC side:

• If there is last minute change from end user, BMC won't just clear all context at /Bios/Settings.
• BMC will check and only remove attribute that is consumed by BIOS. Last minute user change will sty in /Bios/Settings and user will know this change is not consumed yet.