[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <C4834CF8-F81C-4B82-B1A7-1751D50AADB7@suse.de>
Date: Wed, 2 Oct 2013 16:36:05 +0200
From: Alexander Graf <agraf@...e.de>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: Michael Ellerman <michael@...erman.id.au>,
Gleb Natapov <gleb@...hat.com>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Paul Mackerras <paulus@...ba.org>,
linux-kernel@...r.kernel.org, mpm@...enic.com,
herbert@...dor.hengli.com.au, linuxppc-dev@...abs.org,
kvm@...r.kernel.org, kvm-ppc@...r.kernel.org, tytso@....edu
Subject: Re: [PATCH 3/3] KVM: PPC: Book3S: Add support for hwrng found on some powernv systems
On 02.10.2013, at 16:33, Paolo Bonzini wrote:
> Il 02/10/2013 16:08, Alexander Graf ha scritto:
>>> The hwrng is accessible by host userspace via /dev/mem.
>>
>> A guest should live on the same permission level as a user space
>> application. If you run QEMU as UID 1000 without access to /dev/mem, why
>> should the guest suddenly be able to directly access a memory location
>> (MMIO) it couldn't access directly through a normal user space interface.
>>
>> It's basically a layering violation.
>
> With Michael's earlier patch in this series, the hwrng is accessible by
> host userspace via /dev/hwrng, no?
Yes, but there's not token from user space that gets passed into the kernel to check whether access is ok or not. So while QEMU may not have permission to open /dev/hwrng it could spawn a guest that opens it, drains all entropy out of it and thus stall other processes which try to fetch entropy, no?
Maybe I haven't fully grasped the interface yet though :).
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists