linux-kernel - Re: [PATCH v6 4/4] mm: vmalloc: convert vread() to vread

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] [day] [month] [year] [list]

Date:   Wed, 22 Mar 2023 18:36:59 +0000
From:   Lorenzo Stoakes <lstoakes@...il.com>
To:     David Hildenbrand <david@...hat.com>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        linux-fsdevel@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Baoquan He <bhe@...hat.com>,
        Uladzislau Rezki <urezki@...il.com>,
        Matthew Wilcox <willy@...radead.org>,
        Liu Shixin <liushixin2@...wei.com>,
        Jiri Olsa <jolsa@...nel.org>, Jens Axboe <axboe@...nel.dk>,
        Alexander Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH v6 4/4] mm: vmalloc: convert vread() to vread_iter()

On Wed, Mar 22, 2023 at 06:02:34PM +0100, David Hildenbrand wrote:
> On 22.03.23 15:55, Lorenzo Stoakes wrote:
> > Having previously laid the foundation for converting vread() to an iterator
> > function, pull the trigger and do so.
> >
> > This patch attempts to provide minimal refactoring and to reflect the
> > existing logic as best we can, for example we continue to zero portions of
> > memory not read, as before.
> >
> > Overall, there should be no functional difference other than a performance
> > improvement in /proc/kcore access to vmalloc regions.
> >
> > Now we have eliminated the need for a bounce buffer in read_kcore_iter(),
> > we dispense with it, and try to write to user memory optimistically but
> > with faults disabled via copy_page_to_iter_nofault(). We already have
> > preemption disabled by holding a spin lock.
> >
> > If this fails, we fault in and retry a single time. This is a conservative
> > approach intended to avoid spinning on vread_iter() if we repeatedly
> > encouter issues reading from it.
>
> I have to ask again: Can you comment why that is ok? You might end up
> signaling -EFAULT to user space simply because swapping/page
> migration/whatever triggered at the wrong time.
>
> That could break existing user space or which important part am I missing?
>

Actually you're right, this is not ok. I was being mistakenly overcautious
about spinning but in actual fact I don't think this would be an issue
here.

I will respin with a while loop so under no odd timing circumstance do we
break userland.

> --
> Thanks,
>
> David / dhildenb
>