Re: [Qemu-devel] [PATCH v5 1/4] Provide support for the CUSE TPM

[Michael S. Tsirkin]

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.

>