Initialize a whole OBJECT before using it. This is necessary since
an OBJECT may also be used as a HASH_OBJECT via the ANY_OBJECT
union and that HASH_OBJECT can leave bad size inidicators in TPM2B
buffer in the OBJECT. To get rid of this problem we reset the whole
OBJECT to 0 before using it. This is as if the memory for the
OBJECT was just initialized.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Restore the original value of the memory location where data from
a stream was unmarshalled and the unmarshalled value was found to
be illegal. The goal is to not keep illegal values in memory.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Add maxSize parameter to TPM2B_Marshal and assert on it checking
the size of the data intended to be marshaled versus the maximum
buffer size.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reset the buffer size indicator in a TPM2B type of buffer after it failed
the test for the maximum buffer size it allows. This prevents having bad
buffer sizes in memory that can come to haunt us when writing the volatile
state for example.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Run autoupdate on configure.ac and address the following issues:
configure.ac:10: warning: 'AM_CONFIG_HEADER': this macro is obsolete.
configure.ac:10: You should use the 'AC_CONFIG_HEADERS' macro instead.
./lib/autoconf/general.m4:2434: AC_DIAGNOSE is expanded from...
aclocal.m4:1071: AM_CONFIG_HEADER is expanded from...
configure.ac:10: the top level
configure.ac:31: warning: The macro `AC_HELP_STRING' is obsolete.
configure.ac:31: You should run autoupdate.
./lib/autoconf/general.m4:204: AC_HELP_STRING is expanded from...
configure.ac:31: the top level
configure.ac:72: warning: The macro `AC_HELP_STRING' is obsolete.
configure.ac:72: You should run autoupdate.
./lib/autoconf/general.m4:204: AC_HELP_STRING is expanded from...
configure.ac:72: the top level
configure.ac:90: warning: The macro `AC_HELP_STRING' is obsolete.
configure.ac:90: You should run autoupdate.
./lib/autoconf/general.m4:204: AC_HELP_STRING is expanded from...
configure.ac:90: the top level
configure.ac:253: warning: The macro `AC_PROG_LIBTOOL' is obsolete.
configure.ac:253: You should run autoupdate.
m4/libtool.m4:99: AC_PROG_LIBTOOL is expanded from...
configure.ac:253: the top level
configure.ac:258: warning: The macro `AC_HEADER_STDC' is obsolete.
configure.ac:258: You should run autoupdate.
./lib/autoconf/headers.m4:704: AC_HEADER_STDC is expanded from...
configure.ac:258: the top level
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Since swtpm_setup has been rewritten in 'C' now we can drop a few
python dependencies but need libjson-glib-dev as a new dependency
for testing with swtpm's master branch.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Do not call BLOCK_SKIP_READ once rc has been set to any error value.
Therefore, surround all occurrences of BLOCK_SKIP_READ() with tests
of 'rc'.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
The TPM is supposed to provide the output IV in the ivInOut parameter in
CryptSymmetricEncrypt. In the case of using the openssl routines, the
output IV is missed, and the resulting output from the TPM is in the
input IV.
OpenSSL unfortunately does not export EVP_CIPHER_CTX_iv() until
tags/OpenSSL_1_1_0, so we have to fall back to the reference code for
previous OpenSSL versions.
Signed-off-by: William Roberts <william.c.roberts@intel.com>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
This patch fixes a VM suspend/resume issue when externally loaded public
keys are involved.
This patch addresses the bug reported in issue #195 where the saving of
an externally loaded public key's context doesn't work due to the usage of
ANY_CONTEXT_SAVE for saving key contexts. This patch fixes the issue by
creating local versions of TPM_SENSITIVE_Marshal/_Unmarshal that deals
with the case where sensitiveType is not a type of private key but a
public key instead that basically doesn't have much information in
TPM_SENSITIVE but is all zeros instead.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Use TPM_PrintFourLimit in those cases where less than 4 bytes of
valid data may exist. Hashes, nonces, encrypted data, and others
typically have more than 4 bytes but data read from NVRAM or
to be encrypted data may have less.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Sanitize some of the values read from the TPM state stream.
All Coverity discoveries seem to be false positives.
Coverity doesn't like to see array_size being used in the loop even
though it was compared against ARRAY_SIZE() before. We solve this by
using ARRAY_SIZE() as the loop limit now rather than array size.
Compare seed.b.size against PRIMARY_SEED_SIZE even though this is
already being done in TPM2B_Unmarshal().
The num_bytes parameter is sanitized via a comparison involving a
sum over a sum of values, but Coverity doesn't seem to detect this.
Then we have to use it as a loop limit. I don't see another way.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Prevent a potential buffer overrun by checking that EVP_DecryptUpdate()
has not overrun the buffer it was passed in, so this overrun should
never occurr unless EVP_DecryptUpdate() was wrong. Also the pAssert above
it should have taken care of it already.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Coverity complains that the *output* variable passed to
AES_set_encrypt_key contains uninitialized bytes, so we initialize
the variables now.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Coverity complains that nrh may not be initialize when copying nrh.size
from it into the buffer pointer to by nrhp. So resolve this by clearing
nrh at the beginning of the loop and checking 'rc' after the Unmarshal.
Previously we could have copied an uninitialized nrh.size but would have
propagated the rc error code from UINT32_Unmarshal(), so this fix doesn't
really change anything.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
This patch adds a description to the buggy RSAAdjustPrimeCandidate
implementation that can only be properly fixed after 0.7.x.
Reported-by: Nicolas Iooss <nicolas.iooss@ledger.fr>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
This patch ensures that the leading zeros in the b parameter for NIST P521
are being kept so that HLK accepts the returned parameters from
TPM2_ECC_Parameters. Now 66 bytes are reported for 'b' rather than only 65.
Do the same for the 'a' parameter, though that one was properly reported
already because it didn't have any leading zeros.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
This patch addresses issue #177 by fixing some typos and error
reporting inconsistencies (how structures are spelled) in NVMarhsal.c.
Reported-by: Nicolas Iooss <nicolas.iooss@ledger.fr>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
cppcheck has detected the following issues in 2 functions. However,
neither one of the out-of-bounds array access can happen with the
existing code (see comments in patch).
src/tpm2/Session.c:399:5: note: After for loop, slotIndex has value 3
for(slotIndex = 0; slotIndex < MAX_LOADED_SESSIONS; slotIndex++)
^
src/tpm2/Session.c:414:15: note: Assuming condition is false
if(result != TPM_RC_SUCCESS)
^
src/tpm2/Session.c:419:15: note: Array index out of bounds
s_sessions[slotIndex].occupied = TRUE;
^
src/tpm2/Session.c:591:27: error: Array 's_sessions[3]' accessed at index 3, which is out of bounds. [arrayIndexOutOfBounds]
MemoryCopy(&s_sessions[slotIndex].session, session, sizeof(SESSION));
^
src/tpm2/Session.c:571:5: note: After for loop, slotIndex has value 3
for(slotIndex = 0; slotIndex < MAX_LOADED_SESSIONS; slotIndex++)
^
src/tpm2/Session.c:581:8: note: Assuming condition is false
&& contextIndex != s_oldestSavedSession)
^
src/tpm2/Session.c:591:27: note: Array index out of bounds
MemoryCopy(&s_sessions[slotIndex].session, session, sizeof(SESSION));
^
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
UBSAN detects possibly misaligned address when reading out of the
TPM 2's NVRAM and when writing back into it. The NV_RAM_HEADER may
be unaligned like this:
tests/test_tpm2_save_load_state_3.log:tpm2/Marshal.c:117:29: \
runtime error: load of misaligned address 0x7ffcb53b3bca for type 'UINT32', which requires 4 byte alignment
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Make sure that the value of bnK is not short so that the subsequent
BnEccModMult() runs in constant time. We take the same approach as with
the modifications to BnEccGenerateKeyPair() where we request bnK to have
all bytes set (no leading zeros that will be cut away) in case the order
of the curve is as byte boundary. In the other cases we add the order
to bnK, which creates bnK1, which we then use for BnEccModMult's scalar
parameter.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Suggested-by: Charanjit Jutla <csjutla@us.ibm.com>
Reviewed-by: Charanjit Jutla <csjutla@us.ibm.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
To avoid a potential side channel in the EcSchnorr signing algorithm,
enforce that the OpenSSL-generated bnD does not have leading zeros
that may then cause a timing side channel in the BnEccModMult() operation.
We modified BnEccGenerateKeyPair() so it calls BnEccModMult with a scalar
of constant number of bytes (for a particular curve):
In this version of BnEccGenerateKeyPair we take a dual approach to constant
time requirements: For curves whose order is at the byte boundary, e.g.
NIST P224/P256/P384, we make sure that bnD has all bytes set (no leading zeros)
so that OpenSSL BIGNUM code will not reduce the number of bytes and the
subsequent BnEccModMult() would run faster for a shoter value. For all other
curves whose order is not at the byte boundary, e.g. NIST P521, we simply
always add the order to bnD and call BnEccModMult() with the result bnD1,
which leads to the same result.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Suggested-by: Charanjit Jutla <csjutla@us.ibm.com>
Reviewed-by: Charanjit Jutla <csjutla@us.ibm.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Run some additional IBM TSS2 related tests for better code
coverage. We need to switch to Bionic to get the tss2 package.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
