netdev - Re: [PATCH RFC] uaccess: user_access_begin_after_access

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: <20200603020325-mutt-send-email-mst@kernel.org>
Date:   Wed, 3 Jun 2020 02:25:56 -0400
From:   "Michael S. Tsirkin" <mst@...hat.com>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     Jason Wang <jasowang@...hat.com>, linux-kernel@...r.kernel.org,
        netdev@...r.kernel.org
Subject: Re: [PATCH RFC] uaccess: user_access_begin_after_access_ok()

On Wed, Jun 03, 2020 at 05:18:49AM +0100, Al Viro wrote:
> On Wed, Jun 03, 2020 at 11:57:11AM +0800, Jason Wang wrote:
> 
> > > How widely do you hope to stretch the user_access areas, anyway?
> > 
> > 
> > To have best performance for small packets like 64B, if possible, we want to
> > disable STAC not only for the metadata access done by vhost accessors but
> > also the data access via iov iterator.
> 
> If you want to try and convince Linus to go for that, make sure to Cc
> me on that thread.  Always liked quality flame...

It's not about iov the way I see it.

It's a more fine-grained version of "nosmap".

Right now you basically want nosmap if you are running
a workload that does 100 byte reads/writes of userspace memory
all the time.

Which isn't so bad, I'm not sure how much security does smap add at all.
Were there any exploits that it blocked ever since it was introduced?

But in any case, it would be nice to also have an option to make it
possible to disable smap e.g. just for vhost. Not because vhost is
so secure, but simply because user wants this tradeoff.

-- 
MST