From: Greg KH <gregkh@suse.de>
To: KY Srinivasan <kys@microsoft.com>
Cc: Jiri Kosina <jkosina@suse.cz>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
"ohering@suse.com" <ohering@suse.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"virtualization@lists.osdl.org" <virtualization@lists.osdl.org>,
"devel@linuxdriverproject.org" <devel@linuxdriverproject.org>
Subject: Re: [PATCH 1/1] Staging: hv: Move the mouse driver out of staging
Date: Sat, 29 Oct 2011 08:34:09 +0200 [thread overview]
Message-ID: <20111029063409.GB2207@suse.de> (raw)
In-Reply-To: <6E21E5352C11B742B20C142EB499E0481AA53219@TK5EX14MBXC122.redmond.corp.microsoft.com>
On Fri, Oct 28, 2011 at 08:28:11PM +0000, KY Srinivasan wrote:
> > > The guest cannot survive a malicious host; so I think it is safe to say that the
> > > guest can assume the host is following the protocol.
> >
> > That's not good for a very large number of reasons, not the least being
> > that we have no idea how secure the hyperv hypervisor is, so making it
> > so that there isn't an obvious hole into linux through it, would be a
> > good idea.
> >
> > And yes, I'd say the same thing if this was a KVM or Xen driver as well.
> > Please be very defensive in this area of the code, especially as there
> > are no performance issues here.
>
> In the chain of trust, the hypervisor and the host are the foundations
> as far as the guest is concerned, since both the hypervisor and the host
> can affect the guest in ways that the guest has no obvious way to protect itself.
That's true.
> If the hypervisor/host have security holes, there is not much you can do in the guest
> to deal with it.
> In this case, I can add checks but I am not sure how useful it is.
I would prefer to see them here, just to be safe, it can not hurt,
right?
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@suse.de>
To: KY Srinivasan <kys@microsoft.com>
Cc: Jiri Kosina <jkosina@suse.cz>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"devel@linuxdriverproject.org" <devel@linuxdriverproject.org>,
"virtualization@lists.osdl.org" <virtualization@lists.osdl.org>,
"ohering@suse.com" <ohering@suse.com>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>
Subject: Re: [PATCH 1/1] Staging: hv: Move the mouse driver out of staging
Date: Sat, 29 Oct 2011 08:34:09 +0200 [thread overview]
Message-ID: <20111029063409.GB2207@suse.de> (raw)
In-Reply-To: <6E21E5352C11B742B20C142EB499E0481AA53219@TK5EX14MBXC122.redmond.corp.microsoft.com>
On Fri, Oct 28, 2011 at 08:28:11PM +0000, KY Srinivasan wrote:
> > > The guest cannot survive a malicious host; so I think it is safe to say that the
> > > guest can assume the host is following the protocol.
> >
> > That's not good for a very large number of reasons, not the least being
> > that we have no idea how secure the hyperv hypervisor is, so making it
> > so that there isn't an obvious hole into linux through it, would be a
> > good idea.
> >
> > And yes, I'd say the same thing if this was a KVM or Xen driver as well.
> > Please be very defensive in this area of the code, especially as there
> > are no performance issues here.
>
> In the chain of trust, the hypervisor and the host are the foundations
> as far as the guest is concerned, since both the hypervisor and the host
> can affect the guest in ways that the guest has no obvious way to protect itself.
That's true.
> If the hypervisor/host have security holes, there is not much you can do in the guest
> to deal with it.
> In this case, I can add checks but I am not sure how useful it is.
I would prefer to see them here, just to be safe, it can not hurt,
right?
greg k-h
next prev parent reply other threads:[~2011-10-29 6:34 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-26 16:08 [PATCH 1/1] Staging: hv: Move the mouse driver out of staging K. Y. Srinivasan
2011-10-27 10:37 ` Olaf Hering
2011-10-27 13:25 ` KY Srinivasan
2011-10-27 13:25 ` KY Srinivasan
2011-10-28 18:47 ` Jiri Kosina
2011-10-28 19:50 ` KY Srinivasan
2011-10-28 20:03 ` Greg KH
2011-10-28 20:28 ` KY Srinivasan
2011-10-29 6:34 ` Greg KH [this message]
2011-10-29 6:34 ` Greg KH
2011-10-29 14:09 ` KY Srinivasan
2011-10-29 14:09 ` KY Srinivasan
2011-10-29 17:05 ` Jiri Kosina
2011-10-29 17:05 ` Jiri Kosina
2011-10-30 16:16 ` KY Srinivasan
-- strict thread matches above, loose matches on Subject: below --
2011-10-28 22:35 K. Y. Srinivasan
2011-10-28 22:54 ` Jesper Juhl
2011-10-29 6:32 ` Dan Carpenter
2011-10-29 6:32 ` Dan Carpenter
2011-10-30 16:16 ` KY Srinivasan
2011-11-02 22:59 ` Jesper Juhl
2011-11-02 23:04 ` KY Srinivasan
2011-11-05 6:47 ` Dmitry Torokhov
2011-11-07 1:04 ` KY Srinivasan
2011-11-07 5:51 ` Dmitry Torokhov
2011-11-09 0:45 ` KY Srinivasan
2011-11-09 0:49 ` Greg KH
2011-11-09 3:19 ` KY Srinivasan
2011-11-09 14:43 ` KY Srinivasan
2011-11-13 20:02 ` Jiri Kosina
2011-11-14 2:42 ` KY Srinivasan
2011-11-13 20:01 ` Jiri Kosina
2011-11-14 0:47 ` Dmitry Torokhov
2011-11-14 2:45 ` KY Srinivasan
2011-11-14 2:40 ` KY Srinivasan
2011-11-09 17:23 K. Y. Srinivasan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20111029063409.GB2207@suse.de \
--to=gregkh@suse.de \
--cc=devel@linuxdriverproject.org \
--cc=dmitry.torokhov@gmail.com \
--cc=jkosina@suse.cz \
--cc=kys@microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ohering@suse.com \
--cc=virtualization@lists.osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.