From: afzal mohammed <afzal.mohd.ma@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@armlinux.org.uk>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: ARM: vmsplit 4g/4g
Date: Tue, 9 Jun 2020 17:45:06 +0530 [thread overview]
Message-ID: <20200609121506.GA7846@afzalpc> (raw)
In-Reply-To: <20200608151727.GA5017@afzalpc>
Hi,
On Mon, Jun 08, 2020 at 08:47:27PM +0530, afzal mohammed wrote:
> On Mon, Jun 08, 2020 at 04:43:57PM +0200, Arnd Bergmann wrote:
> > There is another difference: get_user_pages_fast() does not return
> > a vm_area_struct pointer, which is where you would check the access
> > permissions. I suppose those pointers could not be returned to callers
> > that don't already hold the mmap_sem.
>
> Ok, thanks for the details, i need to familiarize better with mm.
i was & now more confused w.r.t checking access permission using
vm_area_struct to deny write on a read only user page.
i have been using get_user_pages_fast() w/ FOLL_WRITE in copy_to_user.
Isn't that sufficient ?, afaiu, get_user_pages_fast() will ensure that
w/ FOLL_WRITE, pte has write permission, else no struct page * is
handed back to the caller.
One of the simplified path which could be relevant in the majority of
the cases that i figured out as follows,
get_user_pages_fast
internal_user_pages_fast
gup_pgd_range [ no mmap_sem acquire path]
gup_p4d_range
gup_pud_range
gup_pmd_range
gup_pte_range
if (!pte_access_permitted(pte, flags & FOLL_WRITE))
[ causes to return NULL page if access violation ]
__gup_longterm_unlocked [ mmap_sem acquire path]
get_user_pages_unlocked
__get_user_pages_locked
__get_user_pages
follow_page_mask
follow_p4d_mask
follow_pud_mask
follow_pmd_mask
follow_page_pte
if ((flags & FOLL_WRITE) && !can_follow_write_pte(pte, flags))
[ causes to return NULL page if access violation ]
As far as i could see none of the get_user_pages() caller are passing
struct vm_area_struct ** to get it populated.
And Ingo's series eons ago didn't either pass it or check permission
using it (it was passing a 'write' arguement, which i believe
corrresponds to FOLL_WRITE)
Am i missing something or wrong in the analysis ?
Regards
afzal
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: afzal mohammed <afzal.mohd.ma@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@armlinux.org.uk>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: ARM: vmsplit 4g/4g
Date: Tue, 9 Jun 2020 17:45:06 +0530 [thread overview]
Message-ID: <20200609121506.GA7846@afzalpc> (raw)
In-Reply-To: <20200608151727.GA5017@afzalpc>
Hi,
On Mon, Jun 08, 2020 at 08:47:27PM +0530, afzal mohammed wrote:
> On Mon, Jun 08, 2020 at 04:43:57PM +0200, Arnd Bergmann wrote:
> > There is another difference: get_user_pages_fast() does not return
> > a vm_area_struct pointer, which is where you would check the access
> > permissions. I suppose those pointers could not be returned to callers
> > that don't already hold the mmap_sem.
>
> Ok, thanks for the details, i need to familiarize better with mm.
i was & now more confused w.r.t checking access permission using
vm_area_struct to deny write on a read only user page.
i have been using get_user_pages_fast() w/ FOLL_WRITE in copy_to_user.
Isn't that sufficient ?, afaiu, get_user_pages_fast() will ensure that
w/ FOLL_WRITE, pte has write permission, else no struct page * is
handed back to the caller.
One of the simplified path which could be relevant in the majority of
the cases that i figured out as follows,
get_user_pages_fast
internal_user_pages_fast
gup_pgd_range [ no mmap_sem acquire path]
gup_p4d_range
gup_pud_range
gup_pmd_range
gup_pte_range
if (!pte_access_permitted(pte, flags & FOLL_WRITE))
[ causes to return NULL page if access violation ]
__gup_longterm_unlocked [ mmap_sem acquire path]
get_user_pages_unlocked
__get_user_pages_locked
__get_user_pages
follow_page_mask
follow_p4d_mask
follow_pud_mask
follow_pmd_mask
follow_page_pte
if ((flags & FOLL_WRITE) && !can_follow_write_pte(pte, flags))
[ causes to return NULL page if access violation ]
As far as i could see none of the get_user_pages() caller are passing
struct vm_area_struct ** to get it populated.
And Ingo's series eons ago didn't either pass it or check permission
using it (it was passing a 'write' arguement, which i believe
corrresponds to FOLL_WRITE)
Am i missing something or wrong in the analysis ?
Regards
afzal
next prev parent reply other threads:[~2020-06-09 12:15 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-31 9:32 [PATCH 0/3] Highmem support for 32-bit RISC-V Eric Lin
2020-03-31 9:32 ` Eric Lin
2020-03-31 9:32 ` [PATCH 1/3] riscv/mm: Add pkmap region and CONFIG_HIGHMEM Eric Lin
2020-03-31 9:32 ` Eric Lin
2020-03-31 9:32 ` [PATCH 2/3] riscv/mm: Implement kmap() and kmap_atomic() Eric Lin
2020-03-31 9:32 ` Eric Lin
2020-03-31 9:32 ` [PATCH 3/3] riscv/mm: Add pkmap in print_vm_layout() Eric Lin
2020-03-31 9:32 ` Eric Lin
2020-04-02 9:31 ` [PATCH 0/3] Highmem support for 32-bit RISC-V Arnd Bergmann
2020-04-02 9:31 ` Arnd Bergmann
2020-04-08 3:51 ` Alan Kao
2020-04-08 3:51 ` Alan Kao
2020-04-08 14:40 ` Arnd Bergmann
2020-04-08 14:40 ` Arnd Bergmann
2020-04-14 15:17 ` afzal mohammed
2020-04-14 15:17 ` afzal mohammed
2020-04-14 19:29 ` Arnd Bergmann
2020-04-14 19:29 ` Arnd Bergmann
2020-04-15 13:54 ` afzal mohammed
2020-04-15 13:54 ` afzal mohammed
2020-05-03 14:50 ` afzal mohammed
2020-05-03 14:50 ` afzal mohammed
2020-05-03 20:20 ` Arnd Bergmann
2020-05-03 20:20 ` Arnd Bergmann
2020-05-04 9:10 ` afzal mohammed
2020-05-04 9:10 ` afzal mohammed
2020-05-04 9:10 ` afzal mohammed
2020-05-04 11:27 ` Arnd Bergmann
2020-05-04 11:27 ` Arnd Bergmann
2020-05-04 11:27 ` Arnd Bergmann
2020-05-11 14:21 ` ARM: static kernel in vmalloc space (was Re: [PATCH 0/3] Highmem support for 32-bit RISC-V) afzal mohammed
2020-05-11 14:21 ` afzal mohammed
2020-05-11 15:29 ` Arnd Bergmann
2020-05-11 15:29 ` Arnd Bergmann
2020-05-12 10:47 ` ARM: static kernel in vmalloc space afzal mohammed
2020-05-12 10:47 ` afzal mohammed
2020-05-12 19:49 ` Arnd Bergmann
2020-05-12 19:49 ` Arnd Bergmann
2020-05-14 11:17 ` afzal mohammed
2020-05-14 11:17 ` afzal mohammed
2020-05-14 12:41 ` Arnd Bergmann
2020-05-14 12:41 ` Arnd Bergmann
2020-05-14 13:35 ` afzal mohammed
2020-05-14 13:35 ` afzal mohammed
2020-05-14 14:44 ` afzal mohammed
2020-05-14 14:44 ` afzal mohammed
2020-05-14 15:32 ` Arnd Bergmann
2020-05-14 15:32 ` Arnd Bergmann
2020-05-16 6:06 ` afzal mohammed
2020-05-16 6:06 ` afzal mohammed
2020-05-16 7:35 ` Arnd Bergmann
2020-05-16 7:35 ` Arnd Bergmann
2020-06-07 12:59 ` ARM: vmsplit 4g/4g afzal mohammed
2020-06-07 16:11 ` Russell King - ARM Linux admin
2020-06-07 16:11 ` Russell King - ARM Linux admin
2020-06-08 11:09 ` afzal mohammed
2020-06-08 11:09 ` afzal mohammed
2020-06-10 10:10 ` Linus Walleij
2020-06-10 10:10 ` Linus Walleij
2020-06-12 10:25 ` afzal mohammed
2020-06-12 10:25 ` afzal mohammed
2020-06-15 9:11 ` Linus Walleij
2020-06-15 9:11 ` Linus Walleij
2020-06-15 10:01 ` afzal mohammed
2020-06-15 10:01 ` afzal mohammed
2020-06-07 19:26 ` Arnd Bergmann
2020-06-07 19:26 ` Arnd Bergmann
2020-06-08 11:18 ` afzal mohammed
2020-06-08 11:18 ` afzal mohammed
2020-06-08 14:43 ` Arnd Bergmann
2020-06-08 14:43 ` Arnd Bergmann
2020-06-08 15:17 ` afzal mohammed
2020-06-08 15:17 ` afzal mohammed
2020-06-09 12:15 ` afzal mohammed [this message]
2020-06-09 12:15 ` afzal mohammed
2020-06-09 14:22 ` Arnd Bergmann
2020-06-09 14:22 ` Arnd Bergmann
2020-05-14 16:25 ` ARM: static kernel in vmalloc space Russell King - ARM Linux admin
2020-05-14 16:25 ` Russell King - ARM Linux admin
2020-05-14 21:12 ` Arnd Bergmann
2020-05-14 21:12 ` Arnd Bergmann
2020-05-14 23:40 ` Russell King - ARM Linux admin
2020-05-14 23:40 ` Russell King - ARM Linux admin
2020-05-15 15:41 ` Arnd Bergmann
2020-05-15 15:41 ` Arnd Bergmann
2020-07-30 9:33 ` Linus Walleij
2020-07-30 9:33 ` Linus Walleij
2020-07-30 10:17 ` Arnd Bergmann
2020-07-30 10:17 ` Arnd Bergmann
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=20200609121506.GA7846@afzalpc \
--to=afzal.mohd.ma@gmail.com \
--cc=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
/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.