Linux Virtualization - Sep 2019 - [PATCH v2] vhost: block speculation of translated descriptors

On Wed, Sep 11, 2019 at 02:33:16PM +0200, Michal Hocko
wrote:
> On Wed 11-09-19 08:25:03, Michael S. Tsirkin wrote:
> > On Wed, Sep 11, 2019 at 02:16:28PM +0200, Michal Hocko wrote:
> > > On Wed 11-09-19 08:10:00, Michael S. Tsirkin wrote:
> > > > iovec addresses coming from vhost are assumed to be
> > > > pre-validated, but in fact can be speculated to a value
> > > > out of range.
> > > > 
> > > > Userspace address are later validated with
array_index_nospec so we can
> > > > be sure kernel info does not leak through these addresses,
but vhost
> > > > must also not leak userspace info outside the allowed memory
table to
> > > > guests.
> > > > 
> > > > Following the defence in depth principle, make sure
> > > > the address is not validated out of node range.
> > > > 
> > > > Signed-off-by: Michael S. Tsirkin <mst at redhat.com>
> > > > Acked-by: Jason Wang <jasowang at redhat.com>
> > > > Tested-by: Jason Wang <jasowang at redhat.com>
> > > 
> > > no need to mark fo stable? Other spectre fixes tend to be
backported
> > > even when the security implications are not really clear. The
risk
> > > should be low and better to be covered in case.
> > 
> > This is not really a fix - more a defence in depth thing,
> > quite similar to e.g.  commit b3bbfb3fb5d25776b8e3f361d2eedaabb0b496cd
> > x86: Introduce __uaccess_begin_nospec() and uaccess_try_nospec
> > in scope.
> >
> > That one doesn't seem to be tagged for stable. Was it queued
> > there in practice?
> 
> not marked for stable but it went in. At least to 4.4.
So I guess the answer is I don't know. If you feel it's
justified, then sure, feel free to forward.

-- 
MST

On Wed 11-09-19 09:03:10, Michael S. Tsirkin wrote:
> On Wed, Sep 11, 2019 at 02:33:16PM +0200, Michal Hocko wrote:
> > On Wed 11-09-19 08:25:03, Michael S. Tsirkin wrote:
> > > On Wed, Sep 11, 2019 at 02:16:28PM +0200, Michal Hocko wrote:
> > > > On Wed 11-09-19 08:10:00, Michael S. Tsirkin wrote:
> > > > > iovec addresses coming from vhost are assumed to be
> > > > > pre-validated, but in fact can be speculated to a value
> > > > > out of range.
> > > > > 
> > > > > Userspace address are later validated with
array_index_nospec so we can
> > > > > be sure kernel info does not leak through these
addresses, but vhost
> > > > > must also not leak userspace info outside the allowed
memory table to
> > > > > guests.
> > > > > 
> > > > > Following the defence in depth principle, make sure
> > > > > the address is not validated out of node range.
> > > > > 
> > > > > Signed-off-by: Michael S. Tsirkin <mst at
redhat.com>
> > > > > Acked-by: Jason Wang <jasowang at redhat.com>
> > > > > Tested-by: Jason Wang <jasowang at redhat.com>
> > > > 
> > > > no need to mark fo stable? Other spectre fixes tend to be
backported
> > > > even when the security implications are not really clear.
The risk
> > > > should be low and better to be covered in case.
> > > 
> > > This is not really a fix - more a defence in depth thing,
> > > quite similar to e.g.  commit
b3bbfb3fb5d25776b8e3f361d2eedaabb0b496cd
> > > x86: Introduce __uaccess_begin_nospec() and uaccess_try_nospec
> > > in scope.
> > >
> > > That one doesn't seem to be tagged for stable. Was it queued
> > > there in practice?
> > 
> > not marked for stable but it went in. At least to 4.4.
> 
> So I guess the answer is I don't know. If you feel it's
> justified, then sure, feel free to forward.
Well, that obviously depends on you as a maintainer but the point is
that spectre gatgets are quite hard to find. There is a smack check
AFAIK but that generates quite some false possitives and it is PITA to
crawl through those. If you want an interesting (I am not saying
vulnerable on purpose) gatget then it would be great to mark it for
stable so all stable consumers (disclaimer: I am not one of those) and
add that really great feeling of safety ;)

So take this as my 2c
-- 
Michal Hocko
SUSE Labs

On Wed, Sep 11, 2019 at 03:12:35PM +0200, Michal Hocko
wrote:
> On Wed 11-09-19 09:03:10, Michael S. Tsirkin wrote:
> > On Wed, Sep 11, 2019 at 02:33:16PM +0200, Michal Hocko wrote:
> > > On Wed 11-09-19 08:25:03, Michael S. Tsirkin wrote:
> > > > On Wed, Sep 11, 2019 at 02:16:28PM +0200, Michal Hocko
wrote:
> > > > > On Wed 11-09-19 08:10:00, Michael S. Tsirkin wrote:
> > > > > > iovec addresses coming from vhost are assumed to
be
> > > > > > pre-validated, but in fact can be speculated to a
value
> > > > > > out of range.
> > > > > > 
> > > > > > Userspace address are later validated with
array_index_nospec so we can
> > > > > > be sure kernel info does not leak through these
addresses, but vhost
> > > > > > must also not leak userspace info outside the
allowed memory table to
> > > > > > guests.
> > > > > > 
> > > > > > Following the defence in depth principle, make
sure
> > > > > > the address is not validated out of node range.
> > > > > > 
> > > > > > Signed-off-by: Michael S. Tsirkin <mst at
redhat.com>
> > > > > > Acked-by: Jason Wang <jasowang at
redhat.com>
> > > > > > Tested-by: Jason Wang <jasowang at
redhat.com>
> > > > > 
> > > > > no need to mark fo stable? Other spectre fixes tend to
be backported
> > > > > even when the security implications are not really
clear. The risk
> > > > > should be low and better to be covered in case.
> > > > 
> > > > This is not really a fix - more a defence in depth thing,
> > > > quite similar to e.g.  commit
b3bbfb3fb5d25776b8e3f361d2eedaabb0b496cd
> > > > x86: Introduce __uaccess_begin_nospec() and
uaccess_try_nospec
> > > > in scope.
> > > >
> > > > That one doesn't seem to be tagged for stable. Was it
queued
> > > > there in practice?
> > > 
> > > not marked for stable but it went in. At least to 4.4.
> > 
> > So I guess the answer is I don't know. If you feel it's
> > justified, then sure, feel free to forward.
> 
> Well, that obviously depends on you as a maintainer but the point is
> that spectre gatgets are quite hard to find. There is a smack check
> AFAIK but that generates quite some false possitives and it is PITA to
> crawl through those. If you want an interesting (I am not saying
> vulnerable on purpose) gatget then it would be great to mark it for
> stable so all stable consumers (disclaimer: I am not one of those) and
> add that really great feeling of safety ;)
> 
> So take this as my 2c
OK it seems security at kernel.org is the way to handle these things.
I'll try that.
> -- 
> Michal Hocko
> SUSE Labs