Commit Graph

10 Commits

Author SHA1 Message Date
Stefan Berger
a5977d2018 rev180: Add hierarchy field to OBJECT and use it
Add new field hierarchy to OBJECT and assign values to it and access it.

Beyond the sync with upstream we need to also set the hierachy when
- an older OBJECT is converted to the current OBJECT
- an OBJECT is unmarshalled

Remove ObjectGetHierarchy since it is not needed anymore.

Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
2024-07-25 11:17:42 -04:00
Stefan Berger
7d31d5ae8b rev180: Add TPM2_SetCapability and dependencies
This command does not do much at the moment and should therefore
also not be enabled.

Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
2024-07-18 16:36:02 -04:00
Stefan Berger
f1117d4832 rev180: Add TPM2_NV_ReadPublic2 and dependencies
This command would only need to be enabled if TPM2_NV_DefineSpace2 was
enabled.

Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
2024-07-18 16:36:02 -04:00
Stefan Berger
2803917a09 tpm2: Switch to uncompressed lists and adapt un/marshal functions
Switch the implementation to uncompressed lists (from now on it must
remain uncompressed lists forever) and adapt functions who marshal
and unmarshal arrays that are affected by this switch:

- PERSISTENT_DATA.ppList
- PERSISTENT_DATA.auditCommands

Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
2024-07-15 14:09:09 -04:00
Nicolas Iooss
bbd7b75d71 Fix many misspellings
When testing downgrading from libtpms 0.8 to 0.7 (which is not
possible), the error message which is reported is:

    libtpms/tpm2: Unexpect value for MAX_RSA_KEY_BITS; its value 3072 is
    not = 2048; (version: 2).

codespell (https://github.com/codespell-project/codespell) reports a
misspelling for "Unexpect", which should be "Unexpected". As the project
contains many more misspellings in comments, error messages and
documentation, fix all misspellings reported by codespell.

Signed-off-by: Nicolas Iooss <nicolas.iooss@ledger.fr>
2021-03-02 08:20:25 -05:00
Stefan Berger
61cb823169 tpm2: Start supporting RSA 3072 keys
Start supporting RSA 3072 keys.

NVMarshal.c: We now accept state that was written by libtpms when RSA keys
sizes were 2048 or are 3072, basically less-or-equal than 3072.

Also increase the NVRAM memory size by ~45 kb to accommodate the worst
case where the USER NVRAM is full of 65 2048 bit persisted keys whose 65
OBJECTs are now expanding and need to again fit into the NVRAM. We have
to add exactly 45760 bytes to accomodate this case. See swtpm test
case test_tpm2_save_load_state_2. 65 * 704 = 45760.

NOTE: BETTER TO NOT BACKPORT!!! MAY NEGATIVELY AFFECT UPGRADE PATH!

Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
2020-05-04 08:01:26 -04:00
Stefan Berger
391d878197 tests: Display sizes of components of OBJECT when OBJECT size changes
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
2020-05-04 08:01:26 -04:00
Stefan Berger
3dcaa01d0a tpm2: rev155: Major refactoring of header files
- Introduce Platform.h and replace usage of PlatformData.h and
  Platform_fp.h
- Drop Implementation.h since we now use TpmProfile.h (which we
  prepared previously); many #defines were moved to TpmTypes.h

Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
2020-04-14 16:03:45 -04:00
Stefan Berger
21742dea1e Tests: Add a check for arrays that expand with new commands
Add 2 more tests checking the size of arrays in the PERSISTENT_DATA
structure which expand with new commands.

Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
2020-04-13 08:56:37 -04:00
Stefan Berger
eed97cf008 tpm2: adapt NVRAM offsets and check structure sizes
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>
2018-06-15 18:07:49 -04:00