Michael S. Tsirkin
2020-Jun-29 16:09 UTC
[PATCH v3 1/1] s390: virtio: let arch accept devices without IOMMU feature
On Wed, Jun 17, 2020 at 12:43:57PM +0200, Pierre Morel wrote:> An architecture protecting the guest memory against unauthorized host > access may want to enforce VIRTIO I/O device protection through the > use of VIRTIO_F_IOMMU_PLATFORM. > Let's give a chance to the architecture to accept or not devices > without VIRTIO_F_IOMMU_PLATFORM.I agree it's a bit misleading. Protection is enforced by memory encryption, you can't trust the hypervisor to report the bit correctly so using that as a securoty measure would be pointless. The real gain here is that broken configs are easier to debug. Here's an attempt at a better description: On some architectures, guest knows that VIRTIO_F_IOMMU_PLATFORM is required for virtio to function: e.g. this is the case on s390 protected virt guests, since otherwise guest passes encrypted guest memory to devices, which the device can't read. Without VIRTIO_F_IOMMU_PLATFORM the result is that affected memory (or even a whole page containing it is corrupted). Detect and fail probe instead - that is easier to debug. however, now that we have described what it is (hypervisor misconfiguration) I ask a question: can we be sure this will never ever work? E.g. what if some future hypervisor gains ability to access the protected guest memory in some abstractly secure manner? We are blocking this here, and it's hard to predict the future, and a broken hypervisor can always find ways to crash the guest ... IMHO it would be safer to just print a warning. What do you think?> > Signed-off-by: Pierre Morel <pmorel at linux.ibm.com> > Acked-by: Jason Wang <jasowang at redhat.com> > Acked-by: Christian Borntraeger <borntraeger at de.ibm.com> > --- > arch/s390/mm/init.c | 6 ++++++ > drivers/virtio/virtio.c | 22 ++++++++++++++++++++++ > include/linux/virtio.h | 2 ++ > 3 files changed, 30 insertions(+) > > diff --git a/arch/s390/mm/init.c b/arch/s390/mm/init.c > index 6dc7c3b60ef6..215070c03226 100644 > --- a/arch/s390/mm/init.c > +++ b/arch/s390/mm/init.c > @@ -45,6 +45,7 @@ > #include <asm/kasan.h> > #include <asm/dma-mapping.h> > #include <asm/uv.h> > +#include <linux/virtio.h> > > pgd_t swapper_pg_dir[PTRS_PER_PGD] __section(.bss..swapper_pg_dir); > > @@ -161,6 +162,11 @@ bool force_dma_unencrypted(struct device *dev) > return is_prot_virt_guest(); > } > > +int arch_needs_virtio_iommu_platform(struct virtio_device *dev) > +{ > + return is_prot_virt_guest(); > +} > + > /* protected virtualization */ > static void pv_init(void) > { > diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c > index a977e32a88f2..aa8e01104f86 100644 > --- a/drivers/virtio/virtio.c > +++ b/drivers/virtio/virtio.c > @@ -167,6 +167,21 @@ void virtio_add_status(struct virtio_device *dev, unsigned int status) > } > EXPORT_SYMBOL_GPL(virtio_add_status); > > +/* > + * arch_needs_virtio_iommu_platform - provide arch specific hook when finalizing > + * features for VIRTIO device dev > + * @dev: the VIRTIO device being added > + * > + * Permits the platform to provide architecture specific functionality when > + * devices features are finalized. This is the default implementation. > + * Architecture implementations can override this. > + */ > + > +int __weak arch_needs_virtio_iommu_platform(struct virtio_device *dev) > +{ > + return 0; > +} > + > int virtio_finalize_features(struct virtio_device *dev) > { > int ret = dev->config->finalize_features(dev); > @@ -179,6 +194,13 @@ int virtio_finalize_features(struct virtio_device *dev) > if (!virtio_has_feature(dev, VIRTIO_F_VERSION_1)) > return 0; > > + if (arch_needs_virtio_iommu_platform(dev) && > + !virtio_has_feature(dev, VIRTIO_F_IOMMU_PLATFORM)) { > + dev_warn(&dev->dev, > + "virtio: device must provide VIRTIO_F_IOMMU_PLATFORM\n"); > + return -ENODEV; > + } > + > virtio_add_status(dev, VIRTIO_CONFIG_S_FEATURES_OK); > status = dev->config->get_status(dev); > if (!(status & VIRTIO_CONFIG_S_FEATURES_OK)) { > diff --git a/include/linux/virtio.h b/include/linux/virtio.h > index a493eac08393..e8526ae3463e 100644 > --- a/include/linux/virtio.h > +++ b/include/linux/virtio.h > @@ -195,4 +195,6 @@ void unregister_virtio_driver(struct virtio_driver *drv); > #define module_virtio_driver(__virtio_driver) \ > module_driver(__virtio_driver, register_virtio_driver, \ > unregister_virtio_driver) > + > +int arch_needs_virtio_iommu_platform(struct virtio_device *dev); > #endif /* _LINUX_VIRTIO_H */ > -- > 2.25.1
Pierre Morel
2020-Jun-29 16:48 UTC
[PATCH v3 1/1] s390: virtio: let arch accept devices without IOMMU feature
On 2020-06-29 18:09, Michael S. Tsirkin wrote:> On Wed, Jun 17, 2020 at 12:43:57PM +0200, Pierre Morel wrote: >> An architecture protecting the guest memory against unauthorized host >> access may want to enforce VIRTIO I/O device protection through the >> use of VIRTIO_F_IOMMU_PLATFORM. >> Let's give a chance to the architecture to accept or not devices >> without VIRTIO_F_IOMMU_PLATFORM. > > I agree it's a bit misleading. Protection is enforced by memory > encryption, you can't trust the hypervisor to report the bit correctly > so using that as a securoty measure would be pointless. > The real gain here is that broken configs are easier to > debug. > > Here's an attempt at a better description: > > On some architectures, guest knows that VIRTIO_F_IOMMU_PLATFORM is > required for virtio to function: e.g. this is the case on s390 protected > virt guests, since otherwise guest passes encrypted guest memory to devices, > which the device can't read. Without VIRTIO_F_IOMMU_PLATFORM the > result is that affected memory (or even a whole page containing > it is corrupted). Detect and fail probe instead - that is easier > to debug.Thanks indeed better aside from the "encrypted guest memory": the mechanism used to avoid the access to the guest memory from the host by s390 is not encryption but a hardware feature denying the general host access and allowing pieces of memory to be shared between guest and host. As a consequence the data read from memory is not corrupted but not read at all and the read error kills the hypervizor with a SIGSEGV.> > however, now that we have described what it is (hypervisor > misconfiguration) I ask a question: can we be sure this will never > ever work? E.g. what if some future hypervisor gains ability to > access the protected guest memory in some abstractly secure manner?The goal of the s390 PV feature is to avoid this possibility so I don't think so; however, there is a possibility that some hardware VIRTIO device gain access to the guest's protected memory, even such device does not exist yet. At the moment such device exists we will need a driver for it, at least to enable the feature and apply policies, it is also one of the reasons why a hook to the architecture is interesting.> We are blocking this here, and it's hard to predict the future, > and a broken hypervisor can always find ways to crash the guest ...yes, this is also something to fix on the hypervizor side, Halil is working on it.> > IMHO it would be safer to just print a warning. > What do you think?Sadly, putting a warning may not help as qemu is killed if it accesses the protected memory. Also note that the crash occurs not only on start but also on hotplug. Thanks, Pierre -- Pierre Morel IBM Lab Boeblingen
Michael S. Tsirkin
2020-Jun-29 21:18 UTC
[PATCH v3 1/1] s390: virtio: let arch accept devices without IOMMU feature
On Mon, Jun 29, 2020 at 06:48:28PM +0200, Pierre Morel wrote:> > > On 2020-06-29 18:09, Michael S. Tsirkin wrote: > > On Wed, Jun 17, 2020 at 12:43:57PM +0200, Pierre Morel wrote: > > > An architecture protecting the guest memory against unauthorized host > > > access may want to enforce VIRTIO I/O device protection through the > > > use of VIRTIO_F_IOMMU_PLATFORM. > > > Let's give a chance to the architecture to accept or not devices > > > without VIRTIO_F_IOMMU_PLATFORM. > > > > I agree it's a bit misleading. Protection is enforced by memory > > encryption, you can't trust the hypervisor to report the bit correctly > > so using that as a securoty measure would be pointless. > > The real gain here is that broken configs are easier to > > debug. > > > > Here's an attempt at a better description: > > > > On some architectures, guest knows that VIRTIO_F_IOMMU_PLATFORM is > > required for virtio to function: e.g. this is the case on s390 protected > > virt guests, since otherwise guest passes encrypted guest memory to devices, > > which the device can't read. Without VIRTIO_F_IOMMU_PLATFORM the > > result is that affected memory (or even a whole page containing > > it is corrupted). Detect and fail probe instead - that is easier > > to debug. > > Thanks indeed better aside from the "encrypted guest memory": the mechanism > used to avoid the access to the guest memory from the host by s390 is not > encryption but a hardware feature denying the general host access and > allowing pieces of memory to be shared between guest and host.s/encrypted/protected/> As a consequence the data read from memory is not corrupted but not read at > all and the read error kills the hypervizor with a SIGSEGV.s/(or even a whole page containing it is corrupted)/can not be read and the read error kills the hypervizor with a SIGSEGV/ As an aside, we could maybe handle that more gracefully on the hypervisor side.> > > > > however, now that we have described what it is (hypervisor > > misconfiguration) I ask a question: can we be sure this will never > > ever work? E.g. what if some future hypervisor gains ability to > > access the protected guest memory in some abstractly secure manner? > > The goal of the s390 PV feature is to avoid this possibility so I don't > think so; however, there is a possibility that some hardware VIRTIO device > gain access to the guest's protected memory, even such device does not exist > yet. > > At the moment such device exists we will need a driver for it, at least to > enable the feature and apply policies, it is also one of the reasons why a > hook to the architecture is interesting.Not neessarily, it could also be fully transparent. See e.g. recent AMD andvances allowing unmodified guests with SEV.> > We are blocking this here, and it's hard to predict the future, > > and a broken hypervisor can always find ways to crash the guest ... > > yes, this is also something to fix on the hypervizor side, Halil is working > on it. > > > > > IMHO it would be safer to just print a warning. > > What do you think? > > Sadly, putting a warning may not help as qemu is killed if it accesses the > protected memory. > Also note that the crash occurs not only on start but also on hotplug. > > Thanks, > PierreWell that depends on where does the warning go. If it's on a serial port it might be reported host side before the crash triggers. But interesting point generally. How about a feature to send a warning code or string to host then?> -- > Pierre Morel > IBM Lab Boeblingen