Message ID | 20211214113418.44042-1-frank.heimes@canonical.com |
---|---|
Headers | show |
Series | zcrypt DD: Toleration for new IBM Z Crypto Hardware (LP: 1954680) | expand |
Acked-by: Tim Gardner <tim.gardner@canonical.com> Clean cherry-pick. Isolated to s390 crypto. On 12/14/21 4:34 AM, frank.heimes@canonical.com wrote: > BugLink: https://bugs.launchpad.net/bugs/1954680 > > SRU Justification: > > [Impact] > > * CEX8 hardware CryptoExpress adapter shall support quantum-safe crypto > and therefore require nowadays message sizes > 12kB. > > * This change here is mainly required to support EP11 responses to admin requests at zNext > which due to QS certificates can grow larger than 12kB. > > * It's to cover a minimal patch to provide toleration support for this feature > which shall be back-ported to all distribution releases in service at zNext > > * This SRU requests belongs to the hardware enablement case. > > [Fix] > > * bd39654a2282 bd39654a2282c1a51c044575a6bc00d641d5dfd1 "s390/AP: support new dynamic AP bus size limit" > > [Test Plan] > > * An Ubuntu 20.04 (respectively 21.04) LPAR or z/VM guest is needed > that has access to at least one online crypto domain. > > * Ideally using a CEX8 adapter (but can be too early to get one). > > * Then get the patched kernel installed (see PPA below). > > * And look for the /sys/devices/ap/cardxx/max_msg_size sysfs attributes. > > * On top IBM has some more in-depth zcrypt tests (see also LP#1933805). > > [Where problems could occur] > > * First of all the modification are limited to: > the zcrypt driver ("/drivers/s390/crypto/ap_*.*" and > "/drivers/s390/crypto/zcrypt_*.*") > hence are s390x platform specific and crypto specific and > should even affect CEX8 cards only. > So in case anything fails, it's limited to s390x cryptography, > which usually allows sw fall-backs. > > * The function signature of ap_queue_info and ap_test_queue got modified, > which may lead to issues if called with the old signatures, > but that would be identified by the test compile already. > > * Some minor new structures like 'info', 'ml' got introduced, > but are properly declared and initialized. > > * The way ap_queue_info and ap_card_create get filled and used was changed, > therefore in some code areas slightly different data might be expected, > if not properly adapted to the new way. > But a verification test will prove this. > > * The actual msg length is now handled based on bufsize rather than len > and with that zq is calculated in a different way (using zcrypt_queue_alloc) > which may cause some side effects if not properly (alloc) > or not thoroughly done. > > * in _zcrypt_send_cprb and _zcrypt_send_ep11_cprb some additional calculations > and checks (if-stmts) were introduced, but they look sane. > > * New code to identify older cards got added, since message sizes > 12kB > are supported by CEX8 and higher only. > The dispatcher responsible for choosing the right card and queue is aware > of the individual card AP bus message limit. > But already at the user space tools it should be ensured that the right > card is used. > > * Nevertheless, the patch is not small, hence s390x hardware crypto > zcrypt driver needs to be properly re-tested. > > [Other Info] > > * The above commit/patch is upstream accepted with 5.14. > > * Impish's Kernel 5.13 was already patched, based on LP#1933805. > > * With that the patched zcrypt driver is already tested to some extend > based on Impish (since with these cherry-picks the zcrypt driver is largely > the same now). > > * Hence the SRU is only needed for Focal > and Hirsute (just to avoid regressions on upgrades). > > Harald Freudenberger (1): > s390/AP: support new dynamic AP bus size limit > > drivers/s390/crypto/ap_bus.c | 50 +++++++++++++++++------- > drivers/s390/crypto/ap_bus.h | 11 ++++-- > drivers/s390/crypto/ap_card.c | 16 +++++++- > drivers/s390/crypto/ap_queue.c | 2 +- > drivers/s390/crypto/zcrypt_api.c | 6 +++ > drivers/s390/crypto/zcrypt_cex4.c | 9 ++--- > drivers/s390/crypto/zcrypt_msgtype50.c | 26 ++++++------- > drivers/s390/crypto/zcrypt_msgtype6.c | 54 ++++++++++++++------------ > drivers/s390/crypto/zcrypt_msgtype6.h | 2 - > drivers/s390/crypto/zcrypt_queue.c | 6 +-- > 10 files changed, 116 insertions(+), 66 deletions(-) >
On 14/12/2021 12:34, frank.heimes@canonical.com wrote: > BugLink: https://bugs.launchpad.net/bugs/1954680 > > SRU Justification: > > [Impact] > > * CEX8 hardware CryptoExpress adapter shall support quantum-safe crypto > and therefore require nowadays message sizes > 12kB. > > * This change here is mainly required to support EP11 responses to admin requests at zNext > which due to QS certificates can grow larger than 12kB. > > * It's to cover a minimal patch to provide toleration support for this feature > which shall be back-ported to all distribution releases in service at zNext > > * This SRU requests belongs to the hardware enablement case. > > [Fix] > > * bd39654a2282 bd39654a2282c1a51c044575a6bc00d641d5dfd1 "s390/AP: support new dynamic AP bus size limit" > Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Best regards, Krzysztof
Hi Frank, On 14.12.21 12:34, frank.heimes@canonical.com wrote: > BugLink: https://bugs.launchpad.net/bugs/1954680 The above BugLink is invalid? Could you please point us to the correct LP bug report? Thanks, Kleber > SRU Justification: > > [Impact] > > * CEX8 hardware CryptoExpress adapter shall support quantum-safe crypto > and therefore require nowadays message sizes > 12kB. > > * This change here is mainly required to support EP11 responses to admin requests at zNext > which due to QS certificates can grow larger than 12kB. > > * It's to cover a minimal patch to provide toleration support for this feature > which shall be back-ported to all distribution releases in service at zNext > > * This SRU requests belongs to the hardware enablement case. > > [Fix] > > * bd39654a2282 bd39654a2282c1a51c044575a6bc00d641d5dfd1 "s390/AP: support new dynamic AP bus size limit" > > [Test Plan] > > * An Ubuntu 20.04 (respectively 21.04) LPAR or z/VM guest is needed > that has access to at least one online crypto domain. > > * Ideally using a CEX8 adapter (but can be too early to get one). > > * Then get the patched kernel installed (see PPA below). > > * And look for the /sys/devices/ap/cardxx/max_msg_size sysfs attributes. > > * On top IBM has some more in-depth zcrypt tests (see also LP#1933805). > > [Where problems could occur] > > * First of all the modification are limited to: > the zcrypt driver ("/drivers/s390/crypto/ap_*.*" and > "/drivers/s390/crypto/zcrypt_*.*") > hence are s390x platform specific and crypto specific and > should even affect CEX8 cards only. > So in case anything fails, it's limited to s390x cryptography, > which usually allows sw fall-backs. > > * The function signature of ap_queue_info and ap_test_queue got modified, > which may lead to issues if called with the old signatures, > but that would be identified by the test compile already. > > * Some minor new structures like 'info', 'ml' got introduced, > but are properly declared and initialized. > > * The way ap_queue_info and ap_card_create get filled and used was changed, > therefore in some code areas slightly different data might be expected, > if not properly adapted to the new way. > But a verification test will prove this. > > * The actual msg length is now handled based on bufsize rather than len > and with that zq is calculated in a different way (using zcrypt_queue_alloc) > which may cause some side effects if not properly (alloc) > or not thoroughly done. > > * in _zcrypt_send_cprb and _zcrypt_send_ep11_cprb some additional calculations > and checks (if-stmts) were introduced, but they look sane. > > * New code to identify older cards got added, since message sizes > 12kB > are supported by CEX8 and higher only. > The dispatcher responsible for choosing the right card and queue is aware > of the individual card AP bus message limit. > But already at the user space tools it should be ensured that the right > card is used. > > * Nevertheless, the patch is not small, hence s390x hardware crypto > zcrypt driver needs to be properly re-tested. > > [Other Info] > > * The above commit/patch is upstream accepted with 5.14. > > * Impish's Kernel 5.13 was already patched, based on LP#1933805. > > * With that the patched zcrypt driver is already tested to some extend > based on Impish (since with these cherry-picks the zcrypt driver is largely > the same now). > > * Hence the SRU is only needed for Focal > and Hirsute (just to avoid regressions on upgrades). > > Harald Freudenberger (1): > s390/AP: support new dynamic AP bus size limit > > drivers/s390/crypto/ap_bus.c | 50 +++++++++++++++++------- > drivers/s390/crypto/ap_bus.h | 11 ++++-- > drivers/s390/crypto/ap_card.c | 16 +++++++- > drivers/s390/crypto/ap_queue.c | 2 +- > drivers/s390/crypto/zcrypt_api.c | 6 +++ > drivers/s390/crypto/zcrypt_cex4.c | 9 ++--- > drivers/s390/crypto/zcrypt_msgtype50.c | 26 ++++++------- > drivers/s390/crypto/zcrypt_msgtype6.c | 54 ++++++++++++++------------ > drivers/s390/crypto/zcrypt_msgtype6.h | 2 - > drivers/s390/crypto/zcrypt_queue.c | 6 +-- > 10 files changed, 116 insertions(+), 66 deletions(-) >
On 15.12.21 14:50, Kleber Souza wrote: > Hi Frank, > > On 14.12.21 12:34, frank.heimes@canonical.com wrote: >> BugLink: https://bugs.launchpad.net/bugs/1954680 > The above BugLink is invalid? Could you please point us to the ^ this should have been an affirmation and not a question :) > correct LP bug report? > > > Thanks, > > Kleber > > >> SRU Justification: >> >> [Impact] >> >> * CEX8 hardware CryptoExpress adapter shall support quantum-safe crypto >> and therefore require nowadays message sizes > 12kB. >> >> * This change here is mainly required to support EP11 responses to admin requests at zNext >> which due to QS certificates can grow larger than 12kB. >> >> * It's to cover a minimal patch to provide toleration support for this feature >> which shall be back-ported to all distribution releases in service at zNext >> >> * This SRU requests belongs to the hardware enablement case. >> >> [Fix] >> >> * bd39654a2282 bd39654a2282c1a51c044575a6bc00d641d5dfd1 "s390/AP: support new dynamic AP bus size limit" >> >> [Test Plan] >> >> * An Ubuntu 20.04 (respectively 21.04) LPAR or z/VM guest is needed >> that has access to at least one online crypto domain. >> >> * Ideally using a CEX8 adapter (but can be too early to get one). >> >> * Then get the patched kernel installed (see PPA below). >> >> * And look for the /sys/devices/ap/cardxx/max_msg_size sysfs attributes. >> >> * On top IBM has some more in-depth zcrypt tests (see also LP#1933805). >> >> [Where problems could occur] >> >> * First of all the modification are limited to: >> the zcrypt driver ("/drivers/s390/crypto/ap_*.*" and >> "/drivers/s390/crypto/zcrypt_*.*") >> hence are s390x platform specific and crypto specific and >> should even affect CEX8 cards only. >> So in case anything fails, it's limited to s390x cryptography, >> which usually allows sw fall-backs. >> >> * The function signature of ap_queue_info and ap_test_queue got modified, >> which may lead to issues if called with the old signatures, >> but that would be identified by the test compile already. >> >> * Some minor new structures like 'info', 'ml' got introduced, >> but are properly declared and initialized. >> >> * The way ap_queue_info and ap_card_create get filled and used was changed, >> therefore in some code areas slightly different data might be expected, >> if not properly adapted to the new way. >> But a verification test will prove this. >> >> * The actual msg length is now handled based on bufsize rather than len >> and with that zq is calculated in a different way (using zcrypt_queue_alloc) >> which may cause some side effects if not properly (alloc) >> or not thoroughly done. >> >> * in _zcrypt_send_cprb and _zcrypt_send_ep11_cprb some additional calculations >> and checks (if-stmts) were introduced, but they look sane. >> >> * New code to identify older cards got added, since message sizes > 12kB >> are supported by CEX8 and higher only. >> The dispatcher responsible for choosing the right card and queue is aware >> of the individual card AP bus message limit. >> But already at the user space tools it should be ensured that the right >> card is used. >> >> * Nevertheless, the patch is not small, hence s390x hardware crypto >> zcrypt driver needs to be properly re-tested. >> >> [Other Info] >> >> * The above commit/patch is upstream accepted with 5.14. >> >> * Impish's Kernel 5.13 was already patched, based on LP#1933805. >> >> * With that the patched zcrypt driver is already tested to some extend >> based on Impish (since with these cherry-picks the zcrypt driver is largely >> the same now). >> >> * Hence the SRU is only needed for Focal >> and Hirsute (just to avoid regressions on upgrades). >> >> Harald Freudenberger (1): >> s390/AP: support new dynamic AP bus size limit >> >> drivers/s390/crypto/ap_bus.c | 50 +++++++++++++++++------- >> drivers/s390/crypto/ap_bus.h | 11 ++++-- >> drivers/s390/crypto/ap_card.c | 16 +++++++- >> drivers/s390/crypto/ap_queue.c | 2 +- >> drivers/s390/crypto/zcrypt_api.c | 6 +++ >> drivers/s390/crypto/zcrypt_cex4.c | 9 ++--- >> drivers/s390/crypto/zcrypt_msgtype50.c | 26 ++++++------- >> drivers/s390/crypto/zcrypt_msgtype6.c | 54 ++++++++++++++------------ >> drivers/s390/crypto/zcrypt_msgtype6.h | 2 - >> drivers/s390/crypto/zcrypt_queue.c | 6 +-- >> 10 files changed, 116 insertions(+), 66 deletions(-) >>
Hi Kleber, no, it's the correct LP bug #. But it came in as private - I just made it public (sorry). You should be able to open that URL now ... Bye, Frank On Wed, Dec 15, 2021 at 2:50 PM Kleber Souza <kleber.souza@canonical.com> wrote: > Hi Frank, > > On 14.12.21 12:34, frank.heimes@canonical.com wrote: > > BugLink: https://bugs.launchpad.net/bugs/1954680 > > The above BugLink is invalid? Could you please point us to the > correct LP bug report? > > > Thanks, > > Kleber > > > > SRU Justification: > > > > [Impact] > > > > * CEX8 hardware CryptoExpress adapter shall support quantum-safe crypto > > and therefore require nowadays message sizes > 12kB. > > > > * This change here is mainly required to support EP11 responses to > admin requests at zNext > > which due to QS certificates can grow larger than 12kB. > > > > * It's to cover a minimal patch to provide toleration support for this > feature > > which shall be back-ported to all distribution releases in service > at zNext > > > > * This SRU requests belongs to the hardware enablement case. > > > > [Fix] > > > > * bd39654a2282 bd39654a2282c1a51c044575a6bc00d641d5dfd1 "s390/AP: > support new dynamic AP bus size limit" > > > > [Test Plan] > > > > * An Ubuntu 20.04 (respectively 21.04) LPAR or z/VM guest is needed > > that has access to at least one online crypto domain. > > > > * Ideally using a CEX8 adapter (but can be too early to get one). > > > > * Then get the patched kernel installed (see PPA below). > > > > * And look for the /sys/devices/ap/cardxx/max_msg_size sysfs > attributes. > > > > * On top IBM has some more in-depth zcrypt tests (see also LP#1933805). > > > > [Where problems could occur] > > > > * First of all the modification are limited to: > > the zcrypt driver ("/drivers/s390/crypto/ap_*.*" and > > "/drivers/s390/crypto/zcrypt_*.*") > > hence are s390x platform specific and crypto specific and > > should even affect CEX8 cards only. > > So in case anything fails, it's limited to s390x cryptography, > > which usually allows sw fall-backs. > > > > * The function signature of ap_queue_info and ap_test_queue got > modified, > > which may lead to issues if called with the old signatures, > > but that would be identified by the test compile already. > > > > * Some minor new structures like 'info', 'ml' got introduced, > > but are properly declared and initialized. > > > > * The way ap_queue_info and ap_card_create get filled and used was > changed, > > therefore in some code areas slightly different data might be > expected, > > if not properly adapted to the new way. > > But a verification test will prove this. > > > > * The actual msg length is now handled based on bufsize rather than len > > and with that zq is calculated in a different way (using > zcrypt_queue_alloc) > > which may cause some side effects if not properly (alloc) > > or not thoroughly done. > > > > * in _zcrypt_send_cprb and _zcrypt_send_ep11_cprb some additional > calculations > > and checks (if-stmts) were introduced, but they look sane. > > > > * New code to identify older cards got added, since message sizes > > 12kB > > are supported by CEX8 and higher only. > > The dispatcher responsible for choosing the right card and queue is > aware > > of the individual card AP bus message limit. > > But already at the user space tools it should be ensured that the > right > > card is used. > > > > * Nevertheless, the patch is not small, hence s390x hardware crypto > > zcrypt driver needs to be properly re-tested. > > > > [Other Info] > > > > * The above commit/patch is upstream accepted with 5.14. > > > > * Impish's Kernel 5.13 was already patched, based on LP#1933805. > > > > * With that the patched zcrypt driver is already tested to some extend > > based on Impish (since with these cherry-picks the zcrypt driver is > largely > > the same now). > > > > * Hence the SRU is only needed for Focal > > and Hirsute (just to avoid regressions on upgrades). > > > > Harald Freudenberger (1): > > s390/AP: support new dynamic AP bus size limit > > > > drivers/s390/crypto/ap_bus.c | 50 +++++++++++++++++------- > > drivers/s390/crypto/ap_bus.h | 11 ++++-- > > drivers/s390/crypto/ap_card.c | 16 +++++++- > > drivers/s390/crypto/ap_queue.c | 2 +- > > drivers/s390/crypto/zcrypt_api.c | 6 +++ > > drivers/s390/crypto/zcrypt_cex4.c | 9 ++--- > > drivers/s390/crypto/zcrypt_msgtype50.c | 26 ++++++------- > > drivers/s390/crypto/zcrypt_msgtype6.c | 54 ++++++++++++++------------ > > drivers/s390/crypto/zcrypt_msgtype6.h | 2 - > > drivers/s390/crypto/zcrypt_queue.c | 6 +-- > > 10 files changed, 116 insertions(+), 66 deletions(-) > > > >
On 14.12.21 12:34, frank.heimes@canonical.com wrote: > BugLink: https://bugs.launchpad.net/bugs/1954680 > > SRU Justification: > > [Impact] > > * CEX8 hardware CryptoExpress adapter shall support quantum-safe crypto > and therefore require nowadays message sizes > 12kB. > > * This change here is mainly required to support EP11 responses to admin requests at zNext > which due to QS certificates can grow larger than 12kB. > > * It's to cover a minimal patch to provide toleration support for this feature > which shall be back-ported to all distribution releases in service at zNext > > * This SRU requests belongs to the hardware enablement case. > > [Fix] > > * bd39654a2282 bd39654a2282c1a51c044575a6bc00d641d5dfd1 "s390/AP: support new dynamic AP bus size limit" > > [Test Plan] > > * An Ubuntu 20.04 (respectively 21.04) LPAR or z/VM guest is needed > that has access to at least one online crypto domain. > > * Ideally using a CEX8 adapter (but can be too early to get one). > > * Then get the patched kernel installed (see PPA below). > > * And look for the /sys/devices/ap/cardxx/max_msg_size sysfs attributes. > > * On top IBM has some more in-depth zcrypt tests (see also LP#1933805). > > [Where problems could occur] > > * First of all the modification are limited to: > the zcrypt driver ("/drivers/s390/crypto/ap_*.*" and > "/drivers/s390/crypto/zcrypt_*.*") > hence are s390x platform specific and crypto specific and > should even affect CEX8 cards only. > So in case anything fails, it's limited to s390x cryptography, > which usually allows sw fall-backs. > > * The function signature of ap_queue_info and ap_test_queue got modified, > which may lead to issues if called with the old signatures, > but that would be identified by the test compile already. > > * Some minor new structures like 'info', 'ml' got introduced, > but are properly declared and initialized. > > * The way ap_queue_info and ap_card_create get filled and used was changed, > therefore in some code areas slightly different data might be expected, > if not properly adapted to the new way. > But a verification test will prove this. > > * The actual msg length is now handled based on bufsize rather than len > and with that zq is calculated in a different way (using zcrypt_queue_alloc) > which may cause some side effects if not properly (alloc) > or not thoroughly done. > > * in _zcrypt_send_cprb and _zcrypt_send_ep11_cprb some additional calculations > and checks (if-stmts) were introduced, but they look sane. > > * New code to identify older cards got added, since message sizes > 12kB > are supported by CEX8 and higher only. > The dispatcher responsible for choosing the right card and queue is aware > of the individual card AP bus message limit. > But already at the user space tools it should be ensured that the right > card is used. > > * Nevertheless, the patch is not small, hence s390x hardware crypto > zcrypt driver needs to be properly re-tested. > > [Other Info] > > * The above commit/patch is upstream accepted with 5.14. > > * Impish's Kernel 5.13 was already patched, based on LP#1933805. > > * With that the patched zcrypt driver is already tested to some extend > based on Impish (since with these cherry-picks the zcrypt driver is largely > the same now). > > * Hence the SRU is only needed for Focal > and Hirsute (just to avoid regressions on upgrades). > > Harald Freudenberger (1): > s390/AP: support new dynamic AP bus size limit > > drivers/s390/crypto/ap_bus.c | 50 +++++++++++++++++------- > drivers/s390/crypto/ap_bus.h | 11 ++++-- > drivers/s390/crypto/ap_card.c | 16 +++++++- > drivers/s390/crypto/ap_queue.c | 2 +- > drivers/s390/crypto/zcrypt_api.c | 6 +++ > drivers/s390/crypto/zcrypt_cex4.c | 9 ++--- > drivers/s390/crypto/zcrypt_msgtype50.c | 26 ++++++------- > drivers/s390/crypto/zcrypt_msgtype6.c | 54 ++++++++++++++------------ > drivers/s390/crypto/zcrypt_msgtype6.h | 2 - > drivers/s390/crypto/zcrypt_queue.c | 6 +-- > 10 files changed, 116 insertions(+), 66 deletions(-) > Applied to {focal,hirsute}:linux. Thanks, Kleber