aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2022-03-08KEYS: trusted: Fix trusted key backends when building as moduleAndreas Rammhold1-2/+2
Before this commit the kernel could end up with no trusted key sources even though both of the currently supported backends (TPM and TEE) were compiled as modules. This manifested in the trusted key type not being registered at all. When checking if a CONFIG_… preprocessor variable is defined we only test for the builtin (=y) case and not the module (=m) case. By using the IS_REACHABLE() macro we do test for both cases. Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework") Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Reviewed-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Reviewed-by: Sumit Garg <sumit.garg@linaro.org> Signed-off-by: Andreas Rammhold <andreas@rammhold.de> Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2022-03-08tpm: xen-tpmfront: Use struct_size() helperGustavo A. R. Silva1-4/+4
Make use of the struct_size() helper instead of an open-coded version, in order to avoid any potential type mistakes or integer overflows that, in the worse scenario, could lead to heap overflows. Also, address the following sparse warning: drivers/char/tpm/xen-tpmfront.c:131:16: warning: using sizeof on a flexible structure Link: https://github.com/KSPP/linux/issues/160 Link: https://github.com/KSPP/linux/issues/174 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2022-03-08KEYS: x509: remove dead code that set ->unsupported_sigEric Biggers1-9/+0
The X.509 parser always sets cert->sig->pkey_algo and cert->sig->hash_algo on success, since x509_note_sig_algo() is a mandatory action in the X.509 ASN.1 grammar, and it returns an error if the signature's algorithm is unknown. Thus, remove the dead code which handled these fields being NULL. Acked-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2022-03-08KEYS: x509: remove never-set ->unsupported_key flagEric Biggers3-15/+2
The X.509 parser always sets cert->pub->pkey_algo on success, since x509_extract_key_data() is a mandatory action in the X.509 ASN.1 grammar, and it returns an error if the algorithm is unknown. Thus, remove the dead code which handled this field being NULL. This results in the ->unsupported_key flag never being set, so remove that too. Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2022-03-08KEYS: x509: remove unused fieldsEric Biggers1-2/+0
Remove unused fields from struct x509_parse_context. Acked-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2022-03-08KEYS: x509: clearly distinguish between key and signature algorithmsEric Biggers2-15/+19
An X.509 certificate has two, potentially different public key algorithms: the one used by the certificate's key, and the one that was used to sign the certificate. Some of the naming made it unclear which algorithm was meant. Rename things appropriately: - x509_note_pkey_algo() => x509_note_sig_algo() - algo_oid => sig_algo Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2022-03-08KEYS: fix length validation in keyctl_pkey_params_get_2()Eric Biggers1-3/+11
In many cases, keyctl_pkey_params_get_2() is validating the user buffer lengths against the wrong algorithm properties. Fix it to check against the correct properties. Probably this wasn't noticed before because for all asymmetric keys of the "public_key" subtype, max_data_size == max_sig_size == max_enc_size == max_dec_size. However, this isn't necessarily true for the "asym_tpm" subtype (it should be, but it's not strictly validated). Of course, future key types could have different values as well. Fixes: 00d60fd3b932 ("KEYS: Provide keyctls to drive the new key type ops for asymmetric keys [ver #2]") Cc: <stable@vger.kernel.org> # v4.20+ Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2022-03-08selftests: tpm: add async space test with noneexisting handleTadeusz Struk1-0/+16
Add a test for /dev/tpmrm0 in async mode that checks if the code handles invalid handles correctly. Cc: Jarkko Sakkinen <jarkko@kernel.org> Cc: Shuah Khan <shuah@kernel.org> Cc: <linux-integrity@vger.kernel.org> Cc: <linux-kselftest@vger.kernel.org> Cc: <linux-kernel@vger.kernel.org> Tested-by: Jarkko Sakkinen<jarkko@kernel.org> Signed-off-by: Tadeusz Struk <tstruk@gmail.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2022-03-08tpm: Fix error handling in async workTadeusz Struk1-1/+7
When an invalid (non existing) handle is used in a TPM command, that uses the resource manager interface (/dev/tpmrm0) the resource manager tries to load it from its internal cache, but fails and the tpm_dev_transmit returns an -EINVAL error to the caller. The existing async handler doesn't handle these error cases currently and the condition in the poll handler never returns mask with EPOLLIN set. The result is that the poll call blocks and the application gets stuck until the user_read_timer wakes it up after 120 sec. Change the tpm_dev_async_work function to handle error conditions returned from tpm_dev_transmit they are also reflected in the poll mask and a correct error code could passed back to the caller. Cc: Jarkko Sakkinen <jarkko@kernel.org> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: <linux-integrity@vger.kernel.org> Cc: <stable@vger.kernel.org> Cc: <linux-kernel@vger.kernel.org> Fixes: 9e1b74a63f77 ("tpm: add support for nonblocking operation") Tested-by: Jarkko Sakkinen<jarkko@kernel.org> Signed-off-by: Tadeusz Struk <tstruk@gmail.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2022-03-08selftests: tpm2: Determine available PCR bankStefan Berger2-8/+52
Determine an available PCR bank to be used by a test case by querying the capability TPM2_GET_CAP. The TPM2 returns TPML_PCR_SELECTIONS that contains an array of TPMS_PCR_SELECTIONs indicating available PCR banks and the bitmasks that show which PCRs are enabled in each bank. Collect the data in a dictionary. From the dictionary determine the PCR bank that has the PCRs enabled that the test needs. This avoids test failures with TPM2's that either to not have a SHA-1 bank or whose SHA-1 bank is disabled. Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Tested-by: Jarkko Sakkinen <jarkko@kernel.org> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2022-03-07swiotlb: rework "fix info leak with DMA_FROM_DEVICE"Halil Pasic3-24/+15
Unfortunately, we ended up merging an old version of the patch "fix info leak with DMA_FROM_DEVICE" instead of merging the latest one. Christoph (the swiotlb maintainer), he asked me to create an incremental fix (after I have pointed this out the mix up, and asked him for guidance). So here we go. The main differences between what we got and what was agreed are: * swiotlb_sync_single_for_device is also required to do an extra bounce * We decided not to introduce DMA_ATTR_OVERWRITE until we have exploiters * The implantation of DMA_ATTR_OVERWRITE is flawed: DMA_ATTR_OVERWRITE must take precedence over DMA_ATTR_SKIP_CPU_SYNC Thus this patch removes DMA_ATTR_OVERWRITE, and makes swiotlb_sync_single_for_device() bounce unconditionally (that is, also when dir == DMA_TO_DEVICE) in order do avoid synchronising back stale data from the swiotlb buffer. Let me note, that if the size used with dma_sync_* API is less than the size used with dma_[un]map_*, under certain circumstances we may still end up with swiotlb not being transparent. In that sense, this is no perfect fix either. To get this bullet proof, we would have to bounce the entire mapping/bounce buffer. For that we would have to figure out the starting address, and the size of the mapping in swiotlb_sync_single_for_device(). While this does seem possible, there seems to be no firm consensus on how things are supposed to work. Signed-off-by: Halil Pasic <pasic@linux.ibm.com> Fixes: ddbd89deb7d3 ("swiotlb: fix info leak with DMA_FROM_DEVICE") Cc: stable@vger.kernel.org Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-03-07mtd: rawnand: omap2: Actually prevent invalid configuration and build errorRoger Quadros1-2/+1
The root of the problem is that we are selecting symbols that have dependencies. This can cause random configurations that can fail. The cleanest solution is to avoid using select. This driver uses interfaces from the OMAP_GPMC driver so we have to depend on it instead. Fixes: 4cd335dae3cf ("mtd: rawnand: omap2: Prevent invalid configuration and build error") Signed-off-by: Roger Quadros <rogerq@kernel.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Tested-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/linux-mtd/20220219193600.24892-1-rogerq@kernel.org
2022-03-06Linux 5.17-rc7Linus Torvalds1-1/+1