On Wed, Mar 01, 2017 at 02:24:20PM -0500, Stefan Berger wrote: > > > Anyway, having it in a separate process locked down by SELinux means that > > > even > > > if it does go horribly wrong it won't break qemu. > > > > > > Dave > > Since qemu does blocking ioctls on it and doesn't validate results > > too much it sure can break QEMU - anything from DOS to random > > code execution. That's why we want to keep it in tree and > > start it ourselves - I don't want CVEs claiming not validating > > some parameter we get from it is a remote code execution. > > It should be just a library that yes, we can keep out of > > process for extra security but no, we can't just out random > > stuff in there and never care. > > So then the question is whether the implementation is hopelessly broken or > whether we can defend against buffer overflows so that remote code execution > from a malicious TPM emulator can actually happen? I thought I was properly > checking the alllocated buffer for size and that we won't receive more than > the expected number of bytes, but maybe it needs an additional check for > unreasonable input. > > Example of such code is here: > > https://github.com/stefanberger/qemu-tpm/commit/27d332dc3b2c6bfd0fcd38e69f5c899651f3a5d8#diff-c9d7e2e1d4b17b93ca5580ec2d0d204aR188 > > > FYI: > TPM 1.2 in libtpms: > > $ wc *.c *.h | grep total > 86130 352307 3227530 total > > > TPM 2 in TPM 2 preview branch of libtpms: > > $ wc *.c *.h | grep total > 65318 319043 2651231 total
libtpms seems to be packaged and used outside QEMU, I don't say we need to have that in tree. I thought we were discussing swtpm cuse thing. >
