Linux Kernel Selftest development
 help / color / mirror / Atom feed
From: andrew.murray at arm.com (Andrew Murray)
Subject: [PATCH v15 05/17] arms64: untag user pointers passed to memory syscalls
Date: Tue, 28 May 2019 15:54:11 +0100	[thread overview]
Message-ID: <20190528145411.GA709@e119886-lin.cambridge.arm.com> (raw)
In-Reply-To: <20190527143719.GA59948@MBP.local>

On Mon, May 27, 2019 at 03:37:20PM +0100, Catalin Marinas wrote:
> On Mon, May 06, 2019 at 06:30:51PM +0200, Andrey Konovalov wrote:
> > This patch is a part of a series that extends arm64 kernel ABI to allow to
> > pass tagged user pointers (with the top byte set to something else other
> > than 0x00) as syscall arguments.
> > 
> > This patch allows tagged pointers to be passed to the following memory
> > syscalls: brk, get_mempolicy, madvise, mbind, mincore, mlock, mlock2,
> > mmap, mmap_pgoff, mprotect, mremap, msync, munlock, munmap,
> > remap_file_pages, shmat and shmdt.
> > 
> > This is done by untagging pointers passed to these syscalls in the
> > prologues of their handlers.
> > 
> > Signed-off-by: Andrey Konovalov <andreyknvl at google.com>
> 
> Actually, I don't think any of these wrappers get called (have you
> tested this patch?). Following commit 4378a7d4be30 ("arm64: implement
> syscall wrappers"), I think we have other macro names for overriding the
> sys_* ones.

What is the value in adding these wrappers?

The untagged_addr macro is defined for all in linux/mm.h and these patches
already use untagged_addr in generic code. Thus adding a few more
untagged_addr in the generic syscall handlers (which turn to a nop for most)
is surely better than adding wrappers?

Even if other architectures implement untagged_addr in the future it would
be more consistent if they untagged in the same places and thus not adding
these wrappers enforces that.

Thanks,

Andrew Murray

> 
> -- 
> Catalin
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: andrew.murray@arm.com (Andrew Murray)
Subject: [PATCH v15 05/17] arms64: untag user pointers passed to memory syscalls
Date: Tue, 28 May 2019 15:54:11 +0100	[thread overview]
Message-ID: <20190528145411.GA709@e119886-lin.cambridge.arm.com> (raw)
Message-ID: <20190528145411.YYa_qLn2dffOXYijTR-nds_frij8NBoNjIrOX8YQikk@z> (raw)
In-Reply-To: <20190527143719.GA59948@MBP.local>

On Mon, May 27, 2019@03:37:20PM +0100, Catalin Marinas wrote:
> On Mon, May 06, 2019@06:30:51PM +0200, Andrey Konovalov wrote:
> > This patch is a part of a series that extends arm64 kernel ABI to allow to
> > pass tagged user pointers (with the top byte set to something else other
> > than 0x00) as syscall arguments.
> > 
> > This patch allows tagged pointers to be passed to the following memory
> > syscalls: brk, get_mempolicy, madvise, mbind, mincore, mlock, mlock2,
> > mmap, mmap_pgoff, mprotect, mremap, msync, munlock, munmap,
> > remap_file_pages, shmat and shmdt.
> > 
> > This is done by untagging pointers passed to these syscalls in the
> > prologues of their handlers.
> > 
> > Signed-off-by: Andrey Konovalov <andreyknvl at google.com>
> 
> Actually, I don't think any of these wrappers get called (have you
> tested this patch?). Following commit 4378a7d4be30 ("arm64: implement
> syscall wrappers"), I think we have other macro names for overriding the
> sys_* ones.

What is the value in adding these wrappers?

The untagged_addr macro is defined for all in linux/mm.h and these patches
already use untagged_addr in generic code. Thus adding a few more
untagged_addr in the generic syscall handlers (which turn to a nop for most)
is surely better than adding wrappers?

Even if other architectures implement untagged_addr in the future it would
be more consistent if they untagged in the same places and thus not adding
these wrappers enforces that.

Thanks,

Andrew Murray

> 
> -- 
> Catalin
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2019-05-28 14:54 UTC|newest]

Thread overview: 198+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-06 16:30 [PATCH v15 00/17] arm64: untag user pointers passed to the kernel andreyknvl
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` [PATCH v15 01/17] uaccess: add untagged_addr definition for other arches andreyknvl
2019-05-06 16:30   ` Andrey Konovalov
2019-05-29 14:49   ` khalid.aziz
2019-05-29 14:49     ` Khalid Aziz
2019-05-06 16:30 ` [PATCH v15 02/17] arm64: untag user pointers in access_ok and __uaccess_mask_ptr andreyknvl
2019-05-06 16:30   ` Andrey Konovalov
2019-05-06 16:30 ` [PATCH v15 03/17] lib, arm64: untag user pointers in strn*_user andreyknvl
2019-05-06 16:30   ` Andrey Konovalov
2019-05-22 10:41   ` catalin.marinas
2019-05-22 10:41     ` Catalin Marinas
2019-05-06 16:30 ` [PATCH v15 04/17] mm: add ksys_ wrappers to memory syscalls andreyknvl
2019-05-06 16:30   ` Andrey Konovalov
2019-05-22 10:56   ` catalin.marinas
2019-05-22 10:56     ` Catalin Marinas
2019-05-06 16:30 ` [PATCH v15 05/17] arms64: untag user pointers passed " andreyknvl
2019-05-06 16:30   ` Andrey Konovalov
2019-05-22 11:49   ` catalin.marinas
2019-05-22 11:49     ` Catalin Marinas
2019-05-22 21:16     ` eugenis
2019-05-22 21:16       ` Evgenii Stepanov
2019-05-23  9:04       ` catalin.marinas
2019-05-23  9:04         ` Catalin Marinas
2019-05-24  4:23         ` eugenis
2019-05-24  4:23           ` Evgenii Stepanov
2019-05-24 15:41   ` andrew.murray
2019-05-24 15:41     ` Andrew Murray
2019-05-25  9:57   ` catalin.marinas
2019-05-25  9:57     ` Catalin Marinas
2019-05-27  9:42   ` catalin.marinas
2019-05-27  9:42     ` Catalin Marinas
2019-05-27 14:37   ` catalin.marinas
2019-05-27 14:37     ` Catalin Marinas
2019-05-28 14:54     ` andrew.murray [this message]
2019-05-28 14:54       ` Andrew Murray
2019-05-28 15:40       ` catalin.marinas
2019-05-28 15:40         ` Catalin Marinas
2019-05-28 15:56         ` Dave.Martin
2019-05-28 15:56           ` Dave Martin
2019-05-28 16:34           ` catalin.marinas
2019-05-28 16:34             ` Catalin Marinas
2019-05-29 12:42             ` Dave.Martin
2019-05-29 12:42               ` Dave Martin
2019-05-29 13:23               ` catalin.marinas
2019-05-29 13:23                 ` Catalin Marinas
2019-05-29 15:18                 ` Dave.Martin
2019-05-29 15:18                   ` Dave Martin
2019-05-28 23:33         ` khalid.aziz
2019-05-28 23:33           ` Khalid Aziz
2019-05-29 14:20           ` catalin.marinas
2019-05-29 14:20             ` Catalin Marinas
2019-05-29 19:16             ` khalid.aziz
2019-05-29 19:16               ` Khalid Aziz
2019-05-30 15:11               ` catalin.marinas
2019-05-30 15:11                 ` Catalin Marinas
2019-05-30 16:05                 ` khalid.aziz
2019-05-30 16:05                   ` Khalid Aziz
2019-05-30 16:57                   ` catalin.marinas
2019-05-30 16:57                     ` Catalin Marinas
2019-05-28 13:05   ` catalin.marinas
2019-05-28 13:05     ` Catalin Marinas
2019-05-06 16:30 ` [PATCH v15 06/17] mm: untag user pointers in do_pages_move andreyknvl
2019-05-06 16:30   ` Andrey Konovalov
2019-05-22 11:51   ` catalin.marinas
2019-05-22 11:51     ` Catalin Marinas
2019-05-06 16:30 ` [PATCH v15 07/17] mm, arm64: untag user pointers in mm/gup.c andreyknvl
2019-05-06 16:30   ` Andrey Konovalov
2019-05-22 11:56   ` catalin.marinas
2019-05-22 11:56     ` Catalin Marinas
2019-05-06 16:30 ` [PATCH v15 08/17] mm, arm64: untag user pointers in get_vaddr_frames andreyknvl
2019-05-06 16:30   ` Andrey Konovalov
2019-05-06 16:30 ` [PATCH v15 09/17] fs, arm64: untag user pointers in copy_mount_options andreyknvl
2019-05-06 16:30   ` Andrey Konovalov
2019-05-22 12:09   ` catalin.marinas
2019-05-22 12:09     ` Catalin Marinas
2019-05-06 16:30 ` [PATCH v15 10/17] fs, arm64: untag user pointers in fs/userfaultfd.c andreyknvl
2019-05-06 16:30   ` Andrey Konovalov
2019-05-06 16:30 ` [PATCH v15 11/17] drm/amdgpu, arm64: untag user pointers andreyknvl
2019-05-06 16:30   ` Andrey Konovalov
2019-05-07 16:43   ` Felix.Kuehling
2019-05-07 16:43     ` Kuehling, Felix
2019-05-06 16:30 ` [PATCH v15 12/17] drm/radeon, arm64: untag user pointers in radeon_gem_userptr_ioctl andreyknvl
2019-05-06 16:30   ` Andrey Konovalov
2019-05-07 16:44   ` Felix.Kuehling
2019-05-07 16:44     ` Kuehling, Felix
2019-05-06 16:30 ` [PATCH v15 13/17] IB, arm64: untag user pointers in ib_uverbs_(re)reg_mr() andreyknvl
2019-05-06 16:30   ` Andrey Konovalov
2019-05-06 19:50   ` jgg
2019-05-06 19:50     ` Jason Gunthorpe
2019-05-07  6:33     ` leon
2019-05-07  6:33       ` Leon Romanovsky
2019-05-06 16:31 ` [PATCH v15 14/17] media/v4l2-core, arm64: untag user pointers in videobuf_dma_contig_user_get andreyknvl
2019-05-06 16:31   ` Andrey Konovalov
2019-05-24 13:13   ` mchehab+samsung
2019-05-24 13:13     ` Mauro Carvalho Chehab
2019-05-06 16:31 ` [PATCH v15 15/17] tee, arm64: untag user pointers in tee_shm_register andreyknvl
2019-05-06 16:31   ` Andrey Konovalov
2019-05-06 16:31 ` [PATCH v15 16/17] vfio/type1, arm64: untag user pointers in vaddr_get_pfn andreyknvl
2019-05-06 16:31   ` Andrey Konovalov
2019-05-06 16:31 ` [PATCH v15 17/17] selftests, arm64: add a selftest for passing tagged pointers to kernel andreyknvl
2019-05-06 16:31   ` Andrey Konovalov
2019-05-22 14:16   ` catalin.marinas
2019-05-22 14:16     ` Catalin Marinas
2019-05-31 14:21     ` andreyknvl
2019-05-31 14:21       ` Andrey Konovalov
2019-05-31 16:22       ` catalin.marinas
2019-05-31 16:22         ` Catalin Marinas
2019-05-17 14:49 ` [PATCH v15 00/17] arm64: untag user pointers passed to the kernel catalin.marinas
2019-05-17 14:49   ` Catalin Marinas
2019-05-20 23:53   ` eugenis
2019-05-20 23:53     ` Evgenii Stepanov
2019-05-21 18:29     ` catalin.marinas
2019-05-21 18:29       ` Catalin Marinas
2019-05-22  0:04       ` keescook
2019-05-22  0:04         ` Kees Cook
2019-05-22 10:11         ` catalin.marinas
2019-05-22 10:11           ` Catalin Marinas
2019-05-22 15:30           ` enh
2019-05-22 15:30             ` enh
2019-05-22 16:35             ` catalin.marinas
2019-05-22 16:35               ` Catalin Marinas
2019-05-22 16:58               ` enh
2019-05-22 16:58                 ` enh
2019-05-23 15:21                 ` catalin.marinas
2019-05-23 15:21                   ` Catalin Marinas
2019-05-22 20:47               ` keescook
2019-05-22 20:47                 ` Kees Cook
2019-05-22 23:03                 ` eugenis
2019-05-22 23:03                   ` Evgenii Stepanov
2019-05-22 23:09                   ` enh
2019-05-22 23:09                     ` enh
2019-05-23  7:34                     ` catalin.marinas
2019-05-23  7:34                       ` Catalin Marinas
2019-05-23 14:44                 ` catalin.marinas
2019-05-23 14:44                   ` Catalin Marinas
2019-05-23 15:44                   ` enh
2019-05-23 15:44                     ` enh
2019-05-23 17:00                     ` catalin.marinas
2019-05-23 17:00                       ` Catalin Marinas
2019-05-23 16:38                   ` keescook
2019-05-23 16:38                     ` Kees Cook
2019-05-23 17:43                     ` catalin.marinas
2019-05-23 17:43                       ` Catalin Marinas
2019-05-23 21:31                       ` keescook
2019-05-23 21:31                         ` Kees Cook
2019-05-24 11:20                         ` catalin.marinas
2019-05-24 11:20                           ` Catalin Marinas
2019-05-28 17:02                         ` catalin.marinas
2019-05-28 17:02                           ` Catalin Marinas
2019-06-02  5:06                           ` keescook
2019-06-02  5:06                             ` Kees Cook
2019-05-22 19:21             ` keescook
2019-05-22 19:21               ` Kees Cook
2019-05-22 20:15               ` enh
2019-05-22 20:15                 ` enh
2019-05-23 15:08               ` catalin.marinas
2019-05-23 15:08                 ` Catalin Marinas
2019-05-23 17:51         ` khalid.aziz
2019-05-23 17:51           ` Khalid Aziz
2019-05-23 20:11           ` catalin.marinas
2019-05-23 20:11             ` Catalin Marinas
2019-05-23 21:42             ` khalid.aziz
2019-05-23 21:42               ` Khalid Aziz
2019-05-23 21:49             ` khalid.aziz
2019-05-23 21:49               ` Khalid Aziz
2019-05-24 10:11               ` catalin.marinas
2019-05-24 10:11                 ` Catalin Marinas
2019-05-24 14:25                 ` khalid.aziz
2019-05-24 14:25                   ` Khalid Aziz
2019-05-28 14:14                   ` andreyknvl
2019-05-28 14:14                     ` Andrey Konovalov
2019-05-29  6:11                     ` hch
2019-05-29  6:11                       ` Christoph Hellwig
2019-05-29 12:12                       ` catalin.marinas
2019-05-29 12:12                         ` Catalin Marinas
2019-05-30 17:15                     ` catalin.marinas
2019-05-30 17:15                       ` Catalin Marinas
2019-05-31 14:29                       ` andreyknvl
2019-05-31 14:29                         ` Andrey Konovalov
2019-05-31 16:19                         ` catalin.marinas
2019-05-31 16:19                           ` Catalin Marinas
2019-05-31 16:24                           ` andreyknvl
2019-05-31 16:24                             ` Andrey Konovalov
2019-05-31 16:46                             ` catalin.marinas
2019-05-31 16:46                               ` Catalin Marinas
2019-05-21 18:48   ` jgg
2019-05-21 18:48     ` Jason Gunthorpe
2019-05-22 13:49     ` Dave.Martin
2019-05-22 13:49       ` Dave Martin
2019-05-23  0:20       ` jgg
2019-05-23  0:20         ` Jason Gunthorpe
2019-05-23 10:42         ` Dave.Martin
2019-05-23 10:42           ` Dave Martin
2019-05-23 16:57           ` catalin.marinas
2019-05-23 16:57             ` Catalin Marinas
2019-05-24 14:23             ` Dave.Martin
2019-05-24 14:23               ` Dave Martin

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=20190528145411.GA709@e119886-lin.cambridge.arm.com \
    --to=linux-kselftest@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox