[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e907ce20-b523-eedc-9883-18a5484464be@quicinc.com>
Date: Tue, 13 Jun 2023 10:54:05 -0700
From: Elliot Berman <quic_eberman@...cinc.com>
To: Will Deacon <will@...nel.org>
CC: Alex Elder <elder@...aro.org>,
Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
Prakruthi Deepak Heragu <quic_pheragu@...cinc.com>,
Murali Nalajala <quic_mnalajal@...cinc.com>,
Trilok Soni <quic_tsoni@...cinc.com>,
Srivatsa Vaddagiri <quic_svaddagi@...cinc.com>,
Carl van Schaik <quic_cvanscha@...cinc.com>,
Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
"Arnd Bergmann" <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Jonathan Corbet <corbet@....net>,
"Bagas Sanjaya" <bagasdotme@...il.com>,
Andy Gross <agross@...nel.org>,
"Catalin Marinas" <catalin.marinas@....com>,
Jassi Brar <jassisinghbrar@...il.com>,
<linux-arm-msm@...r.kernel.org>, <devicetree@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <linux-doc@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>, <qperret@...gle.com>,
<quic_cgoldswo@...cinc.com>, <quic_pdaly@...cinc.com>
Subject: Re: [PATCH v13 10/24] gunyah: vm_mgr: Add/remove user memory regions
On 6/5/2023 7:18 AM, Will Deacon wrote:
> Hi Elliot,
>
> [+Quentin since he's looked at the MMU notifiers]
>
> Sorry for the slow response, I got buried in email during a week away.
>
> On Fri, May 19, 2023 at 10:02:29AM -0700, Elliot Berman wrote:
>> On 5/19/2023 4:59 AM, Will Deacon wrote:
>>> On Tue, May 09, 2023 at 01:47:47PM -0700, Elliot Berman wrote:
>>>> + ret = account_locked_vm(ghvm->mm, mapping->npages, true);
>>>> + if (ret)
>>>> + goto free_mapping;
>>>> +
>>>> + mapping->pages = kcalloc(mapping->npages, sizeof(*mapping->pages), GFP_KERNEL_ACCOUNT);
>>>> + if (!mapping->pages) {
>>>> + ret = -ENOMEM;
>>>> + mapping->npages = 0; /* update npages for reclaim */
>>>> + goto unlock_pages;
>>>> + }
>>>> +
>>>> + gup_flags = FOLL_LONGTERM;
>>>> + if (region->flags & GH_MEM_ALLOW_WRITE)
>>>> + gup_flags |= FOLL_WRITE;
>>>> +
>>>> + pinned = pin_user_pages_fast(region->userspace_addr, mapping->npages,
>>>> + gup_flags, mapping->pages);
>>>> + if (pinned < 0) {
>>>> + ret = pinned;
>>>> + goto free_pages;
>>>> + } else if (pinned != mapping->npages) {
>>>> + ret = -EFAULT;
>>>> + mapping->npages = pinned; /* update npages for reclaim */
>>>> + goto unpin_pages;
>>>> + }
>>>
>>> Sorry if I missed it, but I still don't see where you reject file mappings
>>> here.
>>>
>>
>> Sure, I can reject file mappings. I didn't catch that was the ask previously
>> and thought it was only a comment about behavior of file mappings.
>
> I thought the mention of filesystem corruption was clear enough! It's
> definitely something we shouldn't allow.
>
I tried preventing file mappings but this breaks memfd used by crosvm. I
didn't understand the vector you were tracking for filesystem
corruption. I ran a few basic experiments with real filesystem backed
memory mappings and didn't observe corruption, but maybe my experiments
weren't right.
[snip; response to other comments in
https://lore.kernel.org/all/3bd86221-ee2e-d157-009b-11f6ada98537@quicinc.com/]
Powered by blists - more mailing lists