<div dir="ltr"><div>Consolidating my responses to Joel + Patrick.</div><div><br></div><div>Joel:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="color:rgb(0,0,0);font-size:12.8px">I imagine you mean the tmpfs (which is backed by SDRAM).</span></blockquote><div><br></div><div>Yes</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="color:rgb(0,0,0);font-size:12.8px">Have you had input from security/cryptography people for what to do here?</span></blockquote><div><span style="color:rgb(0,0,0);font-size:12.8px"><br></span></div><div><font color="#000000"><span style="font-size:12.8px">Not yet. I'm preparing the phosphor-flash-control repository (locally) with a more detailed design README. I'm going to review this internally with a few people and send out a proposal.</span></font></div><div><font color="#000000"><span style="font-size:12.8px">----</span></font></div><div><font color="#000000"><span style="font-size:12.8px"><br></span></font></div><div><font color="#000000"><span style="font-size:12.8px">Patrick</span></font></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="color:rgb(0,0,0);font-size:12.8px">We have used OpenSSL interfaces for other projects. I'm not stuck on<br></span><span style="color:rgb(0,0,0);font-size:12.8px">that though.</span></blockquote><div><br></div><div>I just used PGP as an example due to familiarity. Will have more details once I actually get some security reviews.</div><div><br></div><div>---</div><div><br></div><div>Re: Software level management</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="color:rgb(0,0,0);font-size:12.8px">Important use cases (from REST perspective):<br></span><span style="color:rgb(0,0,0);font-size:12.8px"> - How does a user identify which levels are installed? Which levels<br></span><span style="color:rgb(0,0,0);font-size:12.8px"> are activated? Which levels are kept for optional downgrade?<br></span><span style="color:rgb(0,0,0);font-size:12.8px"> Which levels are stored on redundant media (ex. dual side flash).<br></span><span style="color:rgb(0,0,0);font-size:12.8px"> - How does a user upload new levels?<br></span><span style="color:rgb(0,0,0);font-size:12.8px"> - How does a user request a level to be activated?</span></blockquote><div><br></div><div>Our traditional approach is host managed. +raltherr might have some more thoughts on this for more bmc-centric software management.</div><div><br></div><div>I think the flash interface will need to be updated to be able to identify exactly what software on the flash (i.e. Active). I don't know if a single version for the entire flash (i.e. bmc_v0.1.0) is appropriate or a version for each individual piece of the bmc image (i.e. uboot_v1.1.0, kernel_v4.7.11, rofs_v1.2.3). Providing this would probably require some compile time specialization on the host flash for different architectures.</div><div><br></div><div>For the other states (persisted, available, backup, etc), those just seem like policies and the actual flash interface shouldn't really care about it (unless the intent is to write the "backup" image to the flash itself).</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 15, 2016 at 3:39 AM, Patrick Williams <span dir="ltr"><<a href="mailto:patrick@stwcx.xyz" target="_blank">patrick@stwcx.xyz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Abhishek,<br>
<br>
On Mon, Nov 14, 2016 at 11:09:30AM -0800, Abhishek Pandit wrote:<br>
> Hey Adriana,<br>
<span class="">><br>
> I've started with how I think the dbus interface should behave:<br>
> <a href="https://gerrit.openbmc-project.xyz/#/c/1166/" rel="noreferrer" target="_blank">https://gerrit.openbmc-<wbr>project.xyz/#/c/1166/</a>.<br>
<br>
</span>I would like to see some better modeling in place for management of code<br>
levels. There may be some overlap with what you are proposing, but you<br>
do seem focused on flashing specifically. Look this over and let me<br>
know what you think, how much overlap there is, and how much you want to<br>
tackle now. We could do some things like temporarily define the<br>
interface in org.openbmc, to indicate eventual deprecation, but allow<br>
you to continue making progress on the function.<br>
<br>
-------------------------<br>
<br>
Important use cases (from REST perspective):<br>
- How does a user identify which levels are installed? Which levels<br>
are activated? Which levels are kept for optional downgrade?<br>
Which levels are stored on redundant media (ex. dual side flash).<br>
- How does a user upload new levels?<br>
- How does a user request a level to be activated?<br>
<br>
Interface modeling:<br>
interface xyz.openbmc_project.Software.<wbr>Level:<br>
property - string Name<br>
- string Version<br>
- enum Persistence { "Temporary", "Persisted" }<br>
- enum State { "Loading", "Verified", "Failed", "Available" }<br>
interface xyz.openbmc_project.FilePath:<br>
< Attached to Software.Level object for images resident on the<br>
BMC and not in flash modules only. Ex. tmpfs ><br>
property - string Path<br>
<br>
interface xyz.openbmc_project.Object.<wbr>Association:<br>
< Associate Software.Level <-> Inventory.Item ><br>
interface xyz.openbmc_project.Software.<wbr>Activation:<br>
< Attached to Object.Assocation object ><br>
property - enum Activation { "Ready", "Activating", "Backup",<br>
"Active"<br>
enum RequestedActivation { "None", "Backup",<br>
"Active" }<br>
integer Progress<br>
<br>
interface xyz.openbmc_project.Object.<wbr>Add:<br>
Used to 'put' new image via HTTPS. Need to confirm with Brad.<br>
interface xyz.openbmc_project.Object.<wbr>Delete:<br>
Used to 'delete' images (from filesystem).<br>
<br>
Object modeling:<br>
/xyz/openbmc_project/software:<br>
Owned by "DownloadManager" which supports Object.Add interface. This<br>
can be called by REST when a user uploads a new level. Later,<br>
we could attach additional interfaces here, possibly owned by<br>
other processes, such as 'Software.DownloadViaTFTP'.<br>
<br>
/xyz/openbmc_project/software/<wbr><id>:<br>
Owned by "DownloadManager" for images which are resident in<br>
tmpfs and a local filesystem ("Available" images). Owned by<br>
"HostUpdater", "BMCUpdater", etc. for images which are resident<br>
in flash modules ("Active", "Backup").<br>
<br>
/xyz/openbmc_project/software/<wbr><id>/imageFor:<br>
Owned by "...Updater" processes and supports the<br>
Object.Association and Software.Activation interfaces.<br>
<br>
Use case solutions:<br>
- How does a user identify which levels are installed?<br>
Enumerate /xyz/openbmc_project/software/<br>
- ... are activated?<br>
List /xyz/openbmc_project/software/ , look at Activation state<br>
on assocations.<br>
- ... are kept for optional downgrade?<br>
List /xyz/openbmc_project/software/ , see images "Persisted",<br>
"Available" and not ("Active" or "Backup").<br>
- How does a user upload new levels?<br>
Do a HTTP PUT to /xyz/openbmc_project/software/<wbr><id>.<br>
- How does a user request a level to be activated?<br>
Set RequestedActivation to "Active", "...Updater" process will<br>
begin activation.<br>
<span class="">><br>
> The overall plan for the flash interface in my head:<br>
><br>
</span>> - REST (or some other) interface receives image + signature to update<br>
> flash<br>
> - Gets saved to filesystem and flash control is called<br>
> - Flash control loads the files into memory and verifies the signature<br>
> - Reference implementation would probably just be pgp<br>
<br>
We have used OpenSSL interfaces for other projects. I'm not stuck on<br>
that though.<br>
<br>
> - Flash control locks the flash device<br>
> - This needs some more thought and probably new dbus interfaces;<br>
> important for host flash<br>
<br>
Yeah, could certainly be a new interface for this on the same object as<br>
Software.Activation.<br>
<br>
> - Image written to flash<br>
> - Lock on flash device released<br>
> - Signal asserted (Done)<br>
<br>
Handled by org.freedesktop.Object.<wbr>PropertyChanged signal on<br>
"Activation" in my modeling above.<br>
<br>
-----------------<br>
<br>
This is just what I had floating around in the back of my head of what<br>
we would [eventually] do for code update. I have some past experience with<br>
CIM and I believe this conceptually lines up with what CIM and Redfish have<br>
both done. I'm certainly not fixed on any particular interface, property,<br>
or enumeration names.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Patrick Williams<br>
</font></span></blockquote></div><br></div>