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>
Prepare the header we are using for writing out the state blobs
for version 2 where we will including the minimum version necessary
to read a particular structure.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Implement TPM2_PersistentAllStore that allocates a buffer big
enough to store all the persistent state and returns that buffer
along with the number of valid bytes.
In this patch we move code from _plat__NvCommit() into this new
function and call this new function now.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Now that patches for writing the state into files and extensions
to their headers have all been applied we can build the TPM 2
code into the library.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
When storing, marshalled the NvChip memory's contents and write the byte
stream into the file rather than the NvChip directly. When reading, assume
we get a marshalled NvChip file and we now need to unmarshal the byte
stream and reconstruct the NvChip.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Some variables are compile-time optional and can be skipped if they are
contained in the byte stream but the implementation does not need them.
We enable this with a few simple macros that we use to replace those parts
where the has_block variables are written into the byte stream. On the
unmarshalling side we check whether the block is in the byte stream and
whether the implementation needs the block and react appropriately
including skipping over the block in the byte stream or skipping over the
code unmarshalling the data.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
