<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I’d also support 11968 being merged. I find the recent discussion and the likelihood of all major distros (supporting the S390x) picking up the patches fairly compelling, especially since the same people will be maintaining it.<div class=""><br class=""><div class="">I would need to go and double check the non-S390x specific parts for possible breakage but the bulk of the changes are S390x specific.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">I support formalising the rules better than we have at the moment. Even if this is in conflict with the above.<br class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Pauli<br class=""><div class="">
<div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; 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; -webkit-text-stroke-width: 0px; text-decoration: none;">-- <br class="">Dr Paul Dale | Distinguished Architect | Cryptographic Foundations <br class="">Phone +61 7 3031 7217<br class="">Oracle Australia</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; 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; -webkit-text-stroke-width: 0px; text-decoration: none;"><br class=""></div><br class="Apple-interchange-newline"></div><br class="Apple-interchange-newline">
</div>
<div><br class=""><blockquote type="cite" class=""><div class="">On 17 Jun 2020, at 1:43 pm, Benjamin Kaduk <<a href="mailto:kaduk@mit.edu" class="">kaduk@mit.edu</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On Tue, Jun 16, 2020 at 02:03:58PM +0100, Matt Caswell wrote:<br class=""><blockquote type="cite" class="">PR 11188 proposes to backport a series of s390x patches to the 1.1.1<br class="">branch. IIUC it includes performance improvements as well as support for<br class="">new hardware instructions.<br class=""><br class="">I think we need to have a much clearer and more explicit policy about<br class="">exactly what is allowed to be backported to a stable branch. For example<br class="">PR #11968 was a significant recent PR that backported AES CTR-DRBG<br class="">performance improvements to the 1.1.1 branch and was allowed (should it<br class="">have been?).<br class=""></blockquote><br class="">I am happy to see 11968 landed; some informal testing that I hope to make<br class="">more formal soon seems to show a ~20% slowdown/regression for large RNG<br class="">requests going from 1.1.1d to 1.1.g, and 11968 provided substantially more<br class="">significant of a speedup (again, very informal testing, though).<br class=""><br class="">In this case you could say that the "bug" is that we're only calling AES on<br class="">a block at a time despite having much more effective backends available for<br class="">multi-block calls.<br class=""><br class=""><blockquote type="cite" class="">We have always said that the stable releases should only receive bug and<br class="">security fixes. Performance improvements have been a bit of a grey area,<br class="">e.g. a few lines of code that significantly improves the performance of<br class="">a particular algorithm or codepath could reasonably be justified as<br class="">"fixing a performance bug". OTOH bringing in whole new files of<br class="">assembler seems to go way beyond that definition.<br class=""></blockquote><br class="">There's probably some semi-subtle distinction to make along the lines of<br class="">"making the algorithm more efficient" vs "using a new algorithm, that<br class="">happens to run faster", with the latter counting as a feature.<br class=""><br class=""><blockquote type="cite" class="">However, when I tried to find a reference to the policy which says<br class="">exactly what we are allowed to backport I could find one. Do we have<br class="">such a thing?<br class=""><br class="">In any case I think we should develop a much more explicit policy that<br class="">will enable us to decide whether PRs such as 11188 are reasonable or<br class="">not. See for example Ubuntu's Stable Release Updates policy:<br class=""></blockquote><br class="">I agree that having something written down will be very useful, even if<br class="">just as a fixed benchmark against which to think about how exceptional any<br class="">given "exception case" is where we want to deviate from it.<br class=""><br class="">-Ben<br class=""><br class=""><blockquote type="cite" class=""><a href="https://wiki.ubuntu.com/StableReleaseUpdates" class="">https://wiki.ubuntu.com/StableReleaseUpdates</a><br class=""><br class=""><br class="">Matt<br class=""></blockquote></div></div></blockquote></div><br class=""></div></div></div></body></html>