| Message ID | 1460641930-5118-1-git-send-email-matanb@mellanox.com (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
And why the hack do we set PROT_EXEC on a mapping of device resources? -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 14/04/2016 16:56, Christoph Hellwig wrote: > And why the hack do we set PROT_EXEC on a mapping of device resources? > Of course we don't (there's no good reason to do that). However, as written in the commit message, when READ_IMPLIES_EXEC is set in current->personality (mm/mmap.c): if ((prot & PROT_READ) && (current->personality & READ_IMPLIES_EXEC)) if (!(file && path_noexec(&file->f_path))) prot |= PROT_EXEC; So, we don't want to fail in these cases. Regards, Matan -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 4/14/2016 4:56 PM, Christoph Hellwig wrote:
> And why the hack do we set PROT_EXEC on a mapping of device resources?
It is set automatically in the kernel for legacy processes that have the
READ_IMPLIES_EXEC personality.
See:
http://lxr.free-electrons.com/source/mm/mmap.c?v=4.5#L1285
https://lwn.net/Articles/94068/
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Apr 14, 2016 at 05:05:42PM +0300, Matan Barak (External) wrote: > On 14/04/2016 16:56, Christoph Hellwig wrote: > >And why the hack do we set PROT_EXEC on a mapping of device resources? > > > > Of course we don't (there's no good reason to do that). > However, as written in the commit message, when READ_IMPLIES_EXEC is set in > current->personality (mm/mmap.c): > > if ((prot & PROT_READ) && (current->personality & READ_IMPLIES_EXEC)) > if (!(file && path_noexec(&file->f_path))) > prot |= PROT_EXEC; > > So, we don't want to fail in these cases. Uh, ok - that's nasty. I somehow only remembered and exec implies read in x86. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 04/14/2016 09:52 AM, Matan Barak wrote: > The current mlx5 code disallows mapping the free running counter of > mlx5 based hardwares when PROT_EXEC is set. > Although this behaviour is correct, Linux does add an implicit VM_EXEC > to the vm_flags if the READ_IMPLIES_EXEC bit is set in the process > personality. This happens for example if the process stack is > executable. > > This causes libmlx5 to output a warning and prevents the user from > reading the free running clock. > Executing the init segment of the hardware isn't a security risk > (at least no more than executing a process own stack), so we just > prevent writes to there. > > Fixes: d69e3bcf7976 ('IB/mlx5: Mmap the HCA's core clock register to > user-space') > Signed-off-by: Matan Barak <matanb@mellanox.com> > Reviewed-by: Haggai Eran <haggaie@mellanox.com> Thanks, applied.
diff --git a/drivers/infiniband/hw/mlx5/main.c b/drivers/infiniband/hw/mlx5/main.c index 5acf346..d7b114b 100644 --- a/drivers/infiniband/hw/mlx5/main.c +++ b/drivers/infiniband/hw/mlx5/main.c @@ -1108,7 +1108,7 @@ static int mlx5_ib_mmap(struct ib_ucontext *ibcontext, struct vm_area_struct *vm if (vma->vm_end - vma->vm_start != PAGE_SIZE) return -EINVAL; - if (vma->vm_flags & (VM_WRITE | VM_EXEC)) + if (vma->vm_flags & VM_WRITE) return -EPERM; /* Don't expose to user-space information it shouldn't have */
The current mlx5 code disallows mapping the free running counter of mlx5 based hardwares when PROT_EXEC is set. Although this behaviour is correct, Linux does add an implicit VM_EXEC to the vm_flags if the READ_IMPLIES_EXEC bit is set in the process personality. This happens for example if the process stack is executable. This causes libmlx5 to output a warning and prevents the user from reading the free running clock. Executing the init segment of the hardware isn't a security risk (at least no more than executing a process own stack), so we just prevent writes to there. Fixes: d69e3bcf7976 ('IB/mlx5: Mmap the HCA's core clock register to user-space') Signed-off-by: Matan Barak <matanb@mellanox.com> Reviewed-by: Haggai Eran <haggaie@mellanox.com> --- Hi Doug, This patch fixes a small issue that occurs when using libmlx5 with READ_IMPLIES_EXEC. When libmlx5 initializes, it mmaps the free running counter clock with PROT_READ permissions. Using READ_IMPLIES_EXEC, PROT_EXEC permission is automatically added and causes mmap to fail. We allow PROT_EXEC mapping, as we don't see it imposes any security risk. Regards, Matan drivers/infiniband/hw/mlx5/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)