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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e54446fb-f9d9-2768-f73f-01a94cf635ea@gmail.com>
Date:   Wed, 14 Apr 2021 23:20:19 +0800
From:   Tianyu Lan <ltykernel@...il.com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     kys@...rosoft.com, haiyangz@...rosoft.com, sthemmin@...rosoft.com,
        wei.liu@...nel.org, Tianyu Lan <Tianyu.Lan@...rosoft.com>,
        linux-hyperv@...r.kernel.org, linux-kernel@...r.kernel.org,
        vkuznets@...hat.com, thomas.lendacky@....com,
        brijesh.singh@....com, sunilmut@...rosoft.com
Subject: Re: [RFC V2 PATCH 8/12] UIO/Hyper-V: Not load UIO HV driver in the
 isolation VM.

Hi Greg:
	Thanks for your review.

On 4/14/2021 12:00 AM, Greg KH wrote:
> On Tue, Apr 13, 2021 at 11:22:13AM -0400, Tianyu Lan wrote:
>> From: Tianyu Lan <Tianyu.Lan@...rosoft.com>
>>
>> UIO HV driver should not load in the isolation VM for security reason.
> 
> Why?  I need a lot more excuse than that.

The reason is that ring buffers have been marked as visible to host.
UIO driver will expose these buffers to user space and user space
driver hasn't done some secure check for data from host. This
is considered as insecure in isolation VM.

> 
> Why would the vm allow UIO devices to bind to it if it was not possible?
> Shouldn't the VM be handling this type of logic and not forcing all
> individual hyperv drivers to do this?
> 
> This feels wrong...

Hypervisor exposes network and storage devices but can't prohibit guest
from binding these devices to UIO driver.

You are right. This should not happen in the individual driver and will
try handling this in the vmbus driver level.



> 
> thanks,
> 
> greg k-h
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ