I'll put constraints in the benchmarks to work around the segfaults (which technically one should do anyway).
I am not the head of the research project behind the benchmark effort; I am only the guy writing the code. Once we complete our work, I'll have to see how the code is being released. If it's released under a public license, I'm sure there would be no objections to having it put in the testsuite. Unfortunately, I am not in a position to make promises =) As to the leak source, the error code mask says that it is from the TPM itself. However, all my calls are through the TSPI, so I'd assume that the tcsd is leaking memory when it crashes and I am unable to free the memory properly. Thanks for your help. On Tue, Aug 10, 2010 at 4:39 PM, Rajiv Andrade <[email protected]>wrote: > Hi Jared, > > Happy to know of such benchmarking development of yours, if you don't mind, > you can send us it for review so it can later be integrated to the TSS > testsuite maybe. > > It could be both Jared, the TSS or TPM leakage. Prior to version 0.3.2 > IIRC, TrouSerS didn't release properly the auth sessions out of a TPM 1.2. > Can you debug and tell which resource is overloading the TPM? > > There are some functions to free the TPM memory indeed, again IIRC, they > are resource oriented, you can't free all of them at once. > > Thanks, > --- > Rajiv Andrade > Security Development > IBM Linux Technology Center > > On Aug 10, 2010, at 5:25 PM, Jared D Schmitz wrote: > > I'm writing a benchmarking suite for the TPM. Since it's TPM-intensive by > definition, there's a lot of memory allocated by tcsd. When an error is > encountered in my code, a cleanup function is called, which frees all memory > and then exits gracefully. But if the error is caused by tcsd segfaulting, > the cleanup functions will all fail because the tcsd can't service the > requests. So is it correct to say that TPM memory is leaked? Right now, > after a few iterations I'll get "Insufficient TPM resources" and I reboot to > free that memory. Is there a function (likely with owner auth) that releases > all memory? This benchmark runs on a test box so there aren't any keys to be > lost. > > (You can cc to the trousers list if you find it relevant) > > On Tue, Aug 10, 2010 at 3:26 PM, Rajiv Andrade > <[email protected]>wrote: > >> Ideally, tpm_rqu_build should do such boundary check for all commands.. >> this will take some time (actually already started this but had to interrupt >> from time to time). >> >> Thanks to the ability to run the tcsd as a non root user I implemented a >> while ago this segfault won't be more than a DoS, which is severe, but not >> as much as a exploitable one that could provide root access. >> >> Thanks >> --- >> Rajiv Andrade >> Security Development >> IBM Linux Technology Center >> >> >> >> On Aug 10, 2010, at 3:38 PM, Jared D Schmitz wrote: >> >> > This occurs with TrouSerS-0.3.6. It IS the responsibility of the caller >> to split any data larger than the RSA public key modulus when sealing to the >> TPM. However, it would be fairly easy to see an application programmer not >> checking the size of user input. I haven't dug into the source, but I'm >> assuming that memcpy is being used to copy data from Tspi_Data_Seal into >> another buffer that is too small. >> > >> > A 1kB file makes it to the TPM and returns error 0x0000002b Invalid data >> size. >> > >> > 2kB and 3kB files return TDDL error 0x00001002 General failure. >> > >> > A 4kB produces a segfault in tcsd. >> > >> > Here is the backtrace from gdb: >> > >> > (gdb) run -f >> > The program being debugged has been started already. >> > Start it from the beginning? (y or n) y >> > Starting program: /usr/local/sbin/tcsd -f >> > [Thread debugging using libthread_db enabled] >> > TCSD trousers 0.3.6: TCSD up and running. >> > [New Thread 0x7ffff79b8710 (LWP 10076)] >> > >> > Program received signal SIGSEGV, Segmentation fault. >> > [Switching to Thread 0x7ffff79b8710 (LWP 10076)] >> > 0x000000311b880ef7 in memcpy () from /lib/libc.so.6 >> > (gdb) backtrace >> > #0 0x000000311b880ef7 in memcpy () from /lib/libc.so.6 >> > #1 0x00000000004078ed in LoadBlob () >> > #2 0x0000000000407989 in LoadBlob_Auth () >> > #3 0x000000000040cacf in tpm_rqu_build () >> > #4 0x000000000042c60a in TCSP_Seal_Internal () >> > #5 0x0000000000000000 in ?? () >> > >> > Architecture is amd64 and the OS is Gentoo Linux running TrouSerS-0.3.6 >> released on SF. >> > >> > >> ------------------------------------------------------------------------------ >> > This SF.net email is sponsored by >> > >> > Make an app they can't live without >> > Enter the BlackBerry Developer Challenge >> > http://p.sf.net/sfu/RIM-dev2dev_______________________________________________ >> > TrouSerS-users mailing list >> > [email protected] >> > https://lists.sourceforge.net/lists/listinfo/trousers-users >> >> > >
------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________ TrouSerS-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/trousers-users
