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.
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. I support formalising the rules better than we have at the moment. Even if this is in conflict with the above. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 17 Jun 2020, at 1:43 pm, Benjamin Kaduk <ka...@mit.edu> wrote: > > On Tue, Jun 16, 2020 at 02:03:58PM +0100, Matt Caswell wrote: >> PR 11188 proposes to backport a series of s390x patches to the 1.1.1 >> branch. IIUC it includes performance improvements as well as support for >> new hardware instructions. >> >> I think we need to have a much clearer and more explicit policy about >> exactly what is allowed to be backported to a stable branch. For example >> PR #11968 was a significant recent PR that backported AES CTR-DRBG >> performance improvements to the 1.1.1 branch and was allowed (should it >> have been?). > > I am happy to see 11968 landed; some informal testing that I hope to make > more formal soon seems to show a ~20% slowdown/regression for large RNG > requests going from 1.1.1d to 1.1.g, and 11968 provided substantially more > significant of a speedup (again, very informal testing, though). > > In this case you could say that the "bug" is that we're only calling AES on > a block at a time despite having much more effective backends available for > multi-block calls. > >> We have always said that the stable releases should only receive bug and >> security fixes. Performance improvements have been a bit of a grey area, >> e.g. a few lines of code that significantly improves the performance of >> a particular algorithm or codepath could reasonably be justified as >> "fixing a performance bug". OTOH bringing in whole new files of >> assembler seems to go way beyond that definition. > > There's probably some semi-subtle distinction to make along the lines of > "making the algorithm more efficient" vs "using a new algorithm, that > happens to run faster", with the latter counting as a feature. > >> However, when I tried to find a reference to the policy which says >> exactly what we are allowed to backport I could find one. Do we have >> such a thing? >> >> In any case I think we should develop a much more explicit policy that >> will enable us to decide whether PRs such as 11188 are reasonable or >> not. See for example Ubuntu's Stable Release Updates policy: > > I agree that having something written down will be very useful, even if > just as a fixed benchmark against which to think about how exceptional any > given "exception case" is where we want to deviate from it. > > -Ben > >> https://wiki.ubuntu.com/StableReleaseUpdates >> >> >> Matt