lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 2 Oct 2013 16:08:47 +0200 From: Alexander Graf <agraf@...e.de> To: Michael Ellerman <michael@...erman.id.au> Cc: Gleb Natapov <gleb@...hat.com>, Benjamin Herrenschmidt <benh@...nel.crashing.org>, Paolo Bonzini <pbonzini@...hat.com>, 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 15:57, Michael Ellerman wrote: > On Wed, 2013-10-02 at 13:02 +0300, Gleb Natapov wrote: >> On Wed, Oct 02, 2013 at 11:50:50AM +0200, Alexander Graf wrote: >>> >>> On 02.10.2013, at 11:11, Alexander Graf wrote: >>> >>> So how do you solve live migration between a kernel that has this patch and one that doesn't? >>> >> Yes, I alluded to it in my email to Paul and Paolo asked also. How this >> interface is disabled? > > Yes that is a valid point. > > We can't disable the interface at runtime, the guest detects its > presence at boot. > > What will happen is the hcall will come through to QEMU, which will > reject it with H_FUNCTION (~= ENOSYS). > > The current pseries-rng driver does not handle that case well, which is > exactly why I sent patches to fix it recently. > > The only other option would be to feed it with /dev/random. > >> Also hwrnd is MMIO in a host why guest needs to >> use hypercall instead of emulating the device (in kernel or somewhere >> else?). > > Because PAPR is a platform specification and it specifies that the > interface is a hypervisor call. We can't just decide we want to do it > differently. > >> Another things is that on a host hwrnd is protected from >> direct userspace access by virtue of been a device, but guest code (event >> kernel mode) is userspace as far as hosts security model goes, so by >> implementing this hypercall in a way that directly access hwrnd you >> expose hwrnd to a userspace unconditionally. Why is this a good idea? > > I'm not sure I follow you. > > 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. 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