The patch 'Recalculate the entrysize in front of every USER_NVRAM blob'
did not properly account for the TPM_HANDLE when recalculating the
entry size of an OBJECT in NVRAM. As a consequence all OBJECTS and NVRAM
indices following the first OBJECT got lost.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Determine which PCR banks need to be restored by determining which PCR banks
are active. We only expect data for active PCR banks and the other ones do
not need data.
The tricky part here is that the TPM 2 maintains a variable that indicates
which PCR banks are active in gp.pcrAllocated and another variable in NVRAM
indicating which ones will become active after a reboot. So far we only saved
the one from NVRAM when marshalling the state but now we have to save the one
holding the current active PCR banks also. The restauration of this variable
needs to happen when we resume the VM with volatile state.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Since the sizeof(TPM_NV_INDEX) and sizeof(OBJECT) may expand when new hash
algorithms are enabled, the size of each entry in the USER_NVRAM may also
expand. We have to account for this when writing the entry size into the
NVRAM and cannot use the one from the unmarshalled state unless it is 0
or the sizes were the same. So the best is to calculate the entry size and
write it again.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Introduce ATTRIBUTE_FORMAT for gcc and clang and use it to check the format
of the printf type function TPMLIB_LogTPM2Error() and the parameters. Fix
several places with errors.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
The unmarshalling of the user NVRAM checks whether the NVRAM size allows us
to write the data into it. Since this function is called before writing the
other data into it (PERSISTENT DATA, etc. at lower offsets in the NVRAM),
we can be sure that the NVRAM is large enough to fit everything. Following
this logic, we should be able to loosen the restriction on the NVRAM size and
need not check what size the NVRAM was on the originating side. Since we will
test the unmarshalling of all the data we should be able to detect if the
local NVRAM size is too small and refuse to take the blob based on the failure
to unmarshal completely.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Make sure that the NVRAM offsets and structure sizes are the same
on all architectures so that we can fill up the NVRAM on one system
and migrate the state to another architecture and it will fit into
the NVRAM space there.
We leave some space for the first few data structures in the NVRAM to
grow. We do this by rounding up the NV_INDEX_RAM_DATA location to the
next kb boundary. This moves it from offset 4356 to 5120 on x86_64 and
from offset 4332 to 5120 on i386. This now leaves us with the same
amount of space for user dynamic NVRAM, which starts beyond offset 5120.
We also pad the OBJECT structure with 4 bytes so that it is the same
size on 32 and 64 bit architectures. This is a data structure that
is used in user dynamic NVRAM and should be the same size on all
architectures so that a full NVRAM always fits.
Also test the size of the NV_INDEX structure, which already has the
same size on all tested architectures (x86_64, i386, arm32, ppc64).
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
This is taken directly from chromiumos TPM2 repository:
commit 172eec5ea9b46ddfe720c854fa719fdf8613b4ed
Author: nagendra modadugu <ngm@google.com>
Date: Fri Sep 16 14:07:13 2016 -0700
Add an initial fuzz test corpus for execute-command
This commit introduces a minimized corpus for
the test in fuzz/execute-command.cc.
The corpus was generated by parsing the TCG test
suite log for messages sent to the TPM. The corpus
includes test cases that produced crashes reported
in chrome-os-partner:56767 and chrome-os-partner:56825.
Future work includes defining a dictionary for the
protocol so that mutations can be more effective,
and also generating test-cases that improve coverage
(e.g. create & store primary key, followed by test case).
BUG=chrome-os-partner:50646
BRANCH=none
TEST=follow instructions in fuzz/README
Change-Id: I24332c0f58996626de9a08e2780595b0b2d76350
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/386443
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Kostya Serebryany <kcc@chromium.org>
Reviewed-by: Mike Aizitsky <aizatsky@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Enable SHA512. Since the TPM 2 expects to see PCR values for
the SHA512 bank in some of its structures, this breaks
compatibility with existing state files.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Also write those structure related to PERSISTENT_ALL to have
a header with version 2 and a tail that allows the state to be
extended and downgraded.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Write the persistent state's EP,SP, and PPSeed values into the
volatile state and check them when reading. This way we can
prevent that arbitrary volatile and persistent state blobs are
used.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Increase the NVRAM memory size to 128kb. That should be it for good.
We accept smaller NVRAM sizes from stored state.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
SHA512 is currently not enabled since until a short while ago the test
data was missing. So before we enable it, we should differentiate between
writing adn reading of SHA384 and SHA512 data by using a different magic
in the header. We assign the existing value of the magic for the SHA384
that we currently use and assign SHA512 a new value.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Adapt the MIN_EVICT_OBJETCS #define value to 7 so that it meeds to
TPM Profile (PTP) Specification and TPM_PT_HR_PERSISTENT_MIN returns
the proper value.
We allow to read the state from a TPM that had a lesser value before.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
If the permanent state was set using SetState() write the permanent
state once we successfully read the volatile state and can use it.
This way we have the state in a file.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
If state was set using SetState() then the cached blob needs
to be passed to the TPM 2 before trying to read the state from
a file.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Coverity is complaining about the case of blockSize == 0. Later on in
CryptSymmetricDecrypt() this case is intercepted as well and
TPM_RC_FAILURE is returned. We just do this a little earlier.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Coverity complains that a couple of variables read from the
stream may not be initialized. It shouldn't be possible to
have them not initialized since we would otherwise have an
error value in rc. Nevertheless, initialize them.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Check the read datasize against an unreasonably large value and
log in case we encounter a bad value. This particular value cannot
be larger than 64k and a few bytes.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
In one case we missed to assign the return value for rc.
In another case check rc value before doing operation.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
The unsigned int needs to be checked as an int against >= 0.
The bit to move needs to be a 1ULL type.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Some versions of gcc complain about the loop counter being
a signed int when compared against a sizeof() results. This
patch fixes this.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Enable a few more algorithm for the TPM2. We have to adapt NVMarshal.c
to allow the enablement of these algorithms without rejecting existing
state. We do this through the 'LE' comparison operator that allows us
to read state from an implementation that didn't have it enabled while
we now have it enabled.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Write comments about the comparison operators used for comparing
compile time options/switches of the state that's being read from
another implementation versus the ones used in the current
implementation.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Write version 2 headers for all versioned structures and append
a trailer that can hold future version data and that can be
skipped. The skipping allows us to downgrade state, meaning if
version 3 appended some data but we read it with version 2,
we don't need the version 3 data but can skip it. We loose data
this way, but can keep the TPM 2 running.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
