On 09/11/2015 05:52 PM, Ross Philipson wrote: > On 09/11/2015 05:21 PM, Ahmed, Safayet (GE Global Research) wrote: >> The current bleeding-edge version of TBOOT contains a fix for a >> stack-overflow problem that was present in the code you cited: >> >> http://sourceforge.net/p/tboot/code/ci/a21e913550866591ba838d49fb3aed43b2f6aadd/tree//tboot/common/printk.c?diff=9040e000ccc4cd85fe8e34616f21e0207808604a >> >> >> The resulting overflow would overwrite strings in the .rodata section >> of TBOOT memory. I'm wondering if this was the cause of the hangs. > > Hmm, well that certainly sounds like a nasty problem. We were curious > about the gigantic buffer on the stack in that routine. It seems the BSP > stack size is still not big enough even with this patch?
I hadn't noticed you made the buffer static in memlog_write. I guess I don't understand why the patch also increases the stack sizes - is that to address some other overflow not related to memlog_write? > > I will try these fixes out, thanks for pointing that out. I suspect we > may have another problem though. The previous terminating condition was > correctly wrapping the log in memlog_write. It seems the new logic for > whether to try to zip does not provide a correct terminating condition > and the zipping could overflow the log. This is consistent with our > problem only showing up on resume from S3 since in this case we are > adding even more to the buffer that is still present from before S3. > Anyway, needs more investigation... I patched my tboot with the patch from above (to make the buffer static) and I still get the hang. I think the problem is more like what I stated above - there is no proper terminating condition on zipping and copying to the main log buffer. > > Thanks > [snip] ------------------------------------------------------------------------------ _______________________________________________ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
