<div dir="auto">Applying patches makes for a security problem as well. Verifying integrity and authenticity of the rootfs requires having trusted hashes. dm-verity does this at a filesystem level. Patching individual binaries would invalidate the signatures.</div><div class="gmail_extra"><br><div class="gmail_quote">On Jan 26, 2017 7:36 AM, "Adriana Kobylak" <<a href="mailto:anoo@linux.vnet.ibm.com">anoo@linux.vnet.ibm.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Jan 26, 2017, at 4:43 AM, Anton D. Kachalov <<a href="mailto:mouse@yandex-team.ru" target="_blank">mouse@yandex-team.ru</a>> wrote:</div><br class="m_-6212822030987642468Apple-interchange-newline"><div><span style="font-family:ArialUnicodeMS;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">Hello.</span><br style="font-family:ArialUnicodeMS;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:ArialUnicodeMS;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:ArialUnicodeMS;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">26.01.2017, 01:32, "Adriana Kobylak" <</span><a href="mailto:anoo@linux.vnet.ibm.com" style="font-family:ArialUnicodeMS;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">anoo@linux.vnet.ibm.com</a><span style="font-family:ArialUnicodeMS;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">>:</span><br style="font-family:ArialUnicodeMS;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite" style="font-family:ArialUnicodeMS;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">General:<br>* Use CRAMFS for read-only partitions, and UBIFS for read-write partitions.<br></blockquote><br style="font-family:ArialUnicodeMS;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:ArialUnicodeMS;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">Why CRAMFS? It's small, but supports only zlib compression, has a 16MB file size limitation and marked as obsolete in kernel tree. Why not SquashFS? It's better for larger projects, has a number of modern compression algos.</span><br style="font-family:ArialUnicodeMS;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"></div></blockquote><div><br></div>You’re right Anton, typo mistake, it should be SquashFS, not CRAMFS.</div><div><br><blockquote type="cite"><div><br style="font-family:ArialUnicodeMS;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite" style="font-family:ArialUnicodeMS;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">PNOR:<br>* Ability to ‘patch’ by copying a Hostboot image *.bin into a designated directory (/usr/local/ for example).<br></blockquote><br style="font-family:ArialUnicodeMS;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:ArialUnicodeMS;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">Would it be good to add support for opkg-based packaging to incrementally (hotfix) system's update? I use it in OpenWRT.</span><br style="font-family:ArialUnicodeMS;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"></div></blockquote><div><br></div>It is a good point, for this we’d need a read-write filesystem to contain the code, and be more formal in updating the revision number in bitbake for the images (currently is set to 0). But since our current use case is about applying temporary (development) patches, not permanent fixes, these changes wouldn’t be a priority at the moment. Also for PNOR images, we don’t own the packaging process (it’s done by the hostboot build).</div><div><br></div><div>As additional information, I’ll be sending a more detailed flow of the PNOR update, including how the dbus objects in Patrick’s Software.Version yaml specification would fit, and how to create the virtual PNOR for the host (memory piece) that the mboxd will be interacting with.</div><div><br><blockquote type="cite"><div><br style="font-family:ArialUnicodeMS;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite" style="font-family:ArialUnicodeMS;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">* Tool to write from PNOR image to BMC format. Implement UBI initially but it could be extended to support different volume managements on other BMCs.<br><br>BMC:<br>*Save multiple firmware versions, starting with 2, to provide the ability to roll-back if needed. If single BMC chip system, save both versions there. If two BMC chip system, save other version in 2nd chip.<br>* Implement various levels of ‘persistency’, such as dev, factory, field. Dev persistency would allow for local patches (/usr/local/ for example) that can be cleared before shipping to customers. Factory mode could delete the location where user data such as network settings resides but preserves the mac address and uuid for example. Etc.<br><br>Thanks,<br><br>Adriana<br>______________________________<wbr>_________________<br>openbmc mailing list<br><a href="mailto:openbmc@lists.ozlabs.org" target="_blank">openbmc@lists.ozlabs.org</a><br><a href="https://lists.ozlabs.org/listinfo/openbmc" target="_blank">https://lists.ozlabs.org/<wbr>listinfo/openbmc</a><br></blockquote><br style="font-family:ArialUnicodeMS;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:ArialUnicodeMS;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">--<span class="m_-6212822030987642468Apple-converted-space"> </span></span><br style="font-family:ArialUnicodeMS;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:ArialUnicodeMS;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">Anton D. Kachalov</span></div></blockquote></div><br></div><br>______________________________<wbr>_________________<br>
openbmc mailing list<br>
<a href="mailto:openbmc@lists.ozlabs.org">openbmc@lists.ozlabs.org</a><br>
<a href="https://lists.ozlabs.org/listinfo/openbmc" rel="noreferrer" target="_blank">https://lists.ozlabs.org/<wbr>listinfo/openbmc</a><br>
<br></blockquote></div></div>