| Message ID | 20160112171738.23496.44254.stgit@tlendack-t1.amdoffice.net (mailing list archive) |
|---|---|
| State | Accepted |
| Delegated to: | Herbert Xu |
| Headers | show |
On 01/12/2016 11:17 AM, Tom Lendacky wrote: > Commit 8996eafdcbad ("crypto: ahash - ensure statesize is non-zero") > added a check to prevent ahash algorithms from successfully registering > if the import and export functions were not implemented. This prevents > an oops in the hash_accept function of algif_hash. This commit causes > the ccp-crypto module SHA support and AES CMAC support from successfully > registering and causing the ccp-crypto module load to fail because the > ahash import and export functions are not implemented. > > Update the CCP Crypto API support to provide import and export support > for ahash algorithms. > > Cc: <stable@vger.kernel.org> # 3.14.x- > Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Herbert, is it possible this patch can be part of Crypto Fixes for 4.5? Thanks, Tom > --- > drivers/crypto/ccp/ccp-crypto-aes-cmac.c | 23 +++++++++++++++++++++++ > drivers/crypto/ccp/ccp-crypto-sha.c | 23 +++++++++++++++++++++++ > 2 files changed, 46 insertions(+) > > diff --git a/drivers/crypto/ccp/ccp-crypto-aes-cmac.c b/drivers/crypto/ccp/ccp-crypto-aes-cmac.c > index d89f20c..00207cf 100644 > --- a/drivers/crypto/ccp/ccp-crypto-aes-cmac.c > +++ b/drivers/crypto/ccp/ccp-crypto-aes-cmac.c > @@ -220,6 +220,26 @@ static int ccp_aes_cmac_digest(struct ahash_request *req) > return ccp_aes_cmac_finup(req); > } > > +static int ccp_aes_cmac_export(struct ahash_request *req, void *out) > +{ > + struct ccp_aes_cmac_req_ctx *rctx = ahash_request_ctx(req); > + struct ccp_aes_cmac_req_ctx *state = out; > + > + *state = *rctx; > + > + return 0; > +} > + > +static int ccp_aes_cmac_import(struct ahash_request *req, const void *in) > +{ > + struct ccp_aes_cmac_req_ctx *rctx = ahash_request_ctx(req); > + const struct ccp_aes_cmac_req_ctx *state = in; > + > + *rctx = *state; > + > + return 0; > +} > + > static int ccp_aes_cmac_setkey(struct crypto_ahash *tfm, const u8 *key, > unsigned int key_len) > { > @@ -352,10 +372,13 @@ int ccp_register_aes_cmac_algs(struct list_head *head) > alg->final = ccp_aes_cmac_final; > alg->finup = ccp_aes_cmac_finup; > alg->digest = ccp_aes_cmac_digest; > + alg->export = ccp_aes_cmac_export; > + alg->import = ccp_aes_cmac_import; > alg->setkey = ccp_aes_cmac_setkey; > > halg = &alg->halg; > halg->digestsize = AES_BLOCK_SIZE; > + halg->statesize = sizeof(struct ccp_aes_cmac_req_ctx); > > base = &halg->base; > snprintf(base->cra_name, CRYPTO_MAX_ALG_NAME, "cmac(aes)"); > diff --git a/drivers/crypto/ccp/ccp-crypto-sha.c b/drivers/crypto/ccp/ccp-crypto-sha.c > index d14b3f2..3aae58d 100644 > --- a/drivers/crypto/ccp/ccp-crypto-sha.c > +++ b/drivers/crypto/ccp/ccp-crypto-sha.c > @@ -207,6 +207,26 @@ static int ccp_sha_digest(struct ahash_request *req) > return ccp_sha_finup(req); > } > > +static int ccp_sha_export(struct ahash_request *req, void *out) > +{ > + struct ccp_sha_req_ctx *rctx = ahash_request_ctx(req); > + struct ccp_sha_req_ctx *state = out; > + > + *state = *rctx; > + > + return 0; > +} > + > +static int ccp_sha_import(struct ahash_request *req, const void *in) > +{ > + struct ccp_sha_req_ctx *rctx = ahash_request_ctx(req); > + const struct ccp_sha_req_ctx *state = in; > + > + *rctx = *state; > + > + return 0; > +} > + > static int ccp_sha_setkey(struct crypto_ahash *tfm, const u8 *key, > unsigned int key_len) > { > @@ -403,9 +423,12 @@ static int ccp_register_sha_alg(struct list_head *head, > alg->final = ccp_sha_final; > alg->finup = ccp_sha_finup; > alg->digest = ccp_sha_digest; > + alg->export = ccp_sha_export; > + alg->import = ccp_sha_import; > > halg = &alg->halg; > halg->digestsize = def->digest_size; > + halg->statesize = sizeof(struct ccp_sha_req_ctx); > > base = &halg->base; > snprintf(base->cra_name, CRYPTO_MAX_ALG_NAME, "%s", def->name); > -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jan 22, 2016 at 11:22:48AM -0600, Tom Lendacky wrote: > On 01/12/2016 11:17 AM, Tom Lendacky wrote: > > Commit 8996eafdcbad ("crypto: ahash - ensure statesize is non-zero") > > added a check to prevent ahash algorithms from successfully registering > > if the import and export functions were not implemented. This prevents > > an oops in the hash_accept function of algif_hash. This commit causes > > the ccp-crypto module SHA support and AES CMAC support from successfully > > registering and causing the ccp-crypto module load to fail because the > > ahash import and export functions are not implemented. > > > > Update the CCP Crypto API support to provide import and export support > > for ahash algorithms. > > > > Cc: <stable@vger.kernel.org> # 3.14.x- > > Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> > > Herbert, is it possible this patch can be part of Crypto Fixes for 4.5? While your patch is probably OK the rctx structure just contains too much crap for me to feel safe about pushing this in at this point in time. So I'd like to have it cook for another cycle. The reason I'm overly cautious is because import/export is directly exposed to user-space so if we get this wrong then we may open up a root hole. Cheers,
On Tue, Jan 12, 2016 at 11:17:38AM -0600, Tom Lendacky wrote: > Commit 8996eafdcbad ("crypto: ahash - ensure statesize is non-zero") > added a check to prevent ahash algorithms from successfully registering > if the import and export functions were not implemented. This prevents > an oops in the hash_accept function of algif_hash. This commit causes > the ccp-crypto module SHA support and AES CMAC support from successfully > registering and causing the ccp-crypto module load to fail because the > ahash import and export functions are not implemented. > > Update the CCP Crypto API support to provide import and export support > for ahash algorithms. > > Cc: <stable@vger.kernel.org> # 3.14.x- > Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Applied.
On 01/25/2016 01:20 AM, Herbert Xu wrote: > On Fri, Jan 22, 2016 at 11:22:48AM -0600, Tom Lendacky wrote: >> On 01/12/2016 11:17 AM, Tom Lendacky wrote: >>> Commit 8996eafdcbad ("crypto: ahash - ensure statesize is non-zero") >>> added a check to prevent ahash algorithms from successfully registering >>> if the import and export functions were not implemented. This prevents >>> an oops in the hash_accept function of algif_hash. This commit causes >>> the ccp-crypto module SHA support and AES CMAC support from successfully >>> registering and causing the ccp-crypto module load to fail because the >>> ahash import and export functions are not implemented. >>> >>> Update the CCP Crypto API support to provide import and export support >>> for ahash algorithms. >>> >>> Cc: <stable@vger.kernel.org> # 3.14.x- >>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> >> >> Herbert, is it possible this patch can be part of Crypto Fixes for 4.5? > > While your patch is probably OK the rctx structure just contains > too much crap for me to feel safe about pushing this in at this > point in time. So I'd like to have it cook for another cycle. > > The reason I'm overly cautious is because import/export is directly > exposed to user-space so if we get this wrong then we may open > up a root hole. Many of the fields in the rctx structure are set during the update operation and don't matter to the driver from an export and import perspective. I included them to make the routines simple, but if user-space exposure is a concern I can pare down the amount of data that is exported and imported. I can send a follow-on patch to do that if you prefer. Thanks, Tom > > Cheers, > -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jan 25, 2016 at 08:58:41AM -0600, Tom Lendacky wrote: > > Many of the fields in the rctx structure are set during the update > operation and don't matter to the driver from an export and import > perspective. I included them to make the routines simple, but if > user-space exposure is a concern I can pare down the amount of data > that is exported and imported. I can send a follow-on patch to do > that if you prefer. I've already merged your patch into cryptodev so it'll eventually make it into mainline and then percolate back via stable. Of course any improvements to the export/import functions are still welcome but I'd prefer to leave the patch in cryptodev for now. Thanks,
diff --git a/drivers/crypto/ccp/ccp-crypto-aes-cmac.c b/drivers/crypto/ccp/ccp-crypto-aes-cmac.c index d89f20c..00207cf 100644 --- a/drivers/crypto/ccp/ccp-crypto-aes-cmac.c +++ b/drivers/crypto/ccp/ccp-crypto-aes-cmac.c @@ -220,6 +220,26 @@ static int ccp_aes_cmac_digest(struct ahash_request *req) return ccp_aes_cmac_finup(req); } +static int ccp_aes_cmac_export(struct ahash_request *req, void *out) +{ + struct ccp_aes_cmac_req_ctx *rctx = ahash_request_ctx(req); + struct ccp_aes_cmac_req_ctx *state = out; + + *state = *rctx; + + return 0; +} + +static int ccp_aes_cmac_import(struct ahash_request *req, const void *in) +{ + struct ccp_aes_cmac_req_ctx *rctx = ahash_request_ctx(req); + const struct ccp_aes_cmac_req_ctx *state = in; + + *rctx = *state; + + return 0; +} + static int ccp_aes_cmac_setkey(struct crypto_ahash *tfm, const u8 *key, unsigned int key_len) { @@ -352,10 +372,13 @@ int ccp_register_aes_cmac_algs(struct list_head *head) alg->final = ccp_aes_cmac_final; alg->finup = ccp_aes_cmac_finup; alg->digest = ccp_aes_cmac_digest; + alg->export = ccp_aes_cmac_export; + alg->import = ccp_aes_cmac_import; alg->setkey = ccp_aes_cmac_setkey; halg = &alg->halg; halg->digestsize = AES_BLOCK_SIZE; + halg->statesize = sizeof(struct ccp_aes_cmac_req_ctx); base = &halg->base; snprintf(base->cra_name, CRYPTO_MAX_ALG_NAME, "cmac(aes)"); diff --git a/drivers/crypto/ccp/ccp-crypto-sha.c b/drivers/crypto/ccp/ccp-crypto-sha.c index d14b3f2..3aae58d 100644 --- a/drivers/crypto/ccp/ccp-crypto-sha.c +++ b/drivers/crypto/ccp/ccp-crypto-sha.c @@ -207,6 +207,26 @@ static int ccp_sha_digest(struct ahash_request *req) return ccp_sha_finup(req); } +static int ccp_sha_export(struct ahash_request *req, void *out) +{ + struct ccp_sha_req_ctx *rctx = ahash_request_ctx(req); + struct ccp_sha_req_ctx *state = out; + + *state = *rctx; + + return 0; +} + +static int ccp_sha_import(struct ahash_request *req, const void *in) +{ + struct ccp_sha_req_ctx *rctx = ahash_request_ctx(req); + const struct ccp_sha_req_ctx *state = in; + + *rctx = *state; + + return 0; +} + static int ccp_sha_setkey(struct crypto_ahash *tfm, const u8 *key, unsigned int key_len) { @@ -403,9 +423,12 @@ static int ccp_register_sha_alg(struct list_head *head, alg->final = ccp_sha_final; alg->finup = ccp_sha_finup; alg->digest = ccp_sha_digest; + alg->export = ccp_sha_export; + alg->import = ccp_sha_import; halg = &alg->halg; halg->digestsize = def->digest_size; + halg->statesize = sizeof(struct ccp_sha_req_ctx); base = &halg->base; snprintf(base->cra_name, CRYPTO_MAX_ALG_NAME, "%s", def->name);
Commit 8996eafdcbad ("crypto: ahash - ensure statesize is non-zero") added a check to prevent ahash algorithms from successfully registering if the import and export functions were not implemented. This prevents an oops in the hash_accept function of algif_hash. This commit causes the ccp-crypto module SHA support and AES CMAC support from successfully registering and causing the ccp-crypto module load to fail because the ahash import and export functions are not implemented. Update the CCP Crypto API support to provide import and export support for ahash algorithms. Cc: <stable@vger.kernel.org> # 3.14.x- Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> --- drivers/crypto/ccp/ccp-crypto-aes-cmac.c | 23 +++++++++++++++++++++++ drivers/crypto/ccp/ccp-crypto-sha.c | 23 +++++++++++++++++++++++ 2 files changed, 46 insertions(+) -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html