| Message ID | 20220909212731.1373355-2-abrestic@rivosinc.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v3,1/2] riscv: Make VM_WRITE imply VM_READ | expand |
On 09/09/2022 22:27, Andrew Bresticker wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > Commit 2139619bcad7 ("riscv: mmap with PROT_WRITE but no PROT_READ is > invalid") made mmap() return EINVAL if PROT_WRITE was set wihtout > PROT_READ with the justification that a write-only PTE is considered a > reserved PTE permission bit pattern in the privileged spec. This check > is unnecessary since we let VM_WRITE imply VM_READ on RISC-V, and it is > inconsistent with other architectures that don't support write-only PTEs, > creating a potential software portability issue. Just remove the check > altogether and let PROT_WRITE imply PROT_READ as is the case on other > architectures. > > Note that this also allows PROT_WRITE|PROT_EXEC mappings which were > disallowed prior to the aforementioned commit; PROT_READ is implied in > such mappings as well. > > Fixes: 2139619bcad7 ("riscv: mmap with PROT_WRITE but no PROT_READ is invalid") For the naive members of the audience such as myself, this patch came after a non-fixes patch in the series. What is the dependence of this patch on the other one (if any)? Thanks, Conor. > Reviewed-by: Atish Patra <atishp@rivosinc.com> > Signed-off-by: Andrew Bresticker <abrestic@rivosinc.com> > --- > v1 -> v2: Update access_error() to account for write-implies-read > v2 -> v3: Separate into two commits > --- > arch/riscv/kernel/sys_riscv.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/arch/riscv/kernel/sys_riscv.c b/arch/riscv/kernel/sys_riscv.c > index 571556bb9261..5d3f2fbeb33c 100644 > --- a/arch/riscv/kernel/sys_riscv.c > +++ b/arch/riscv/kernel/sys_riscv.c > @@ -18,9 +18,6 @@ static long riscv_sys_mmap(unsigned long addr, unsigned long len, > if (unlikely(offset & (~PAGE_MASK >> page_shift_offset))) > return -EINVAL; > > - if (unlikely((prot & PROT_WRITE) && !(prot & PROT_READ))) > - return -EINVAL; > - > return ksys_mmap_pgoff(addr, len, prot, flags, fd, > offset >> (PAGE_SHIFT - page_shift_offset)); > } > -- > 2.25.1 > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
On Thu, Sep 15, 2022 at 12:56 PM <Conor.Dooley@microchip.com> wrote: > > On 09/09/2022 22:27, Andrew Bresticker wrote: > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > > > Commit 2139619bcad7 ("riscv: mmap with PROT_WRITE but no PROT_READ is > > invalid") made mmap() return EINVAL if PROT_WRITE was set wihtout > > PROT_READ with the justification that a write-only PTE is considered a > > reserved PTE permission bit pattern in the privileged spec. This check > > is unnecessary since we let VM_WRITE imply VM_READ on RISC-V, and it is > > inconsistent with other architectures that don't support write-only PTEs, > > creating a potential software portability issue. Just remove the check > > altogether and let PROT_WRITE imply PROT_READ as is the case on other > > architectures. > > > > Note that this also allows PROT_WRITE|PROT_EXEC mappings which were > > disallowed prior to the aforementioned commit; PROT_READ is implied in > > such mappings as well. > > > > Fixes: 2139619bcad7 ("riscv: mmap with PROT_WRITE but no PROT_READ is invalid") > > For the naive members of the audience such as myself, this patch > came after a non-fixes patch in the series. What is the dependence > of this patch on the other one (if any)? This patch is dependent on the first. Happy to re-spin with a "Fixes" tag on the first patch (or maybe Palmer can add when applying). -Andrew > Thanks, > Conor. > > > Reviewed-by: Atish Patra <atishp@rivosinc.com> > > Signed-off-by: Andrew Bresticker <abrestic@rivosinc.com> > > --- > > v1 -> v2: Update access_error() to account for write-implies-read > > v2 -> v3: Separate into two commits > > --- > > arch/riscv/kernel/sys_riscv.c | 3 --- > > 1 file changed, 3 deletions(-) > > > > diff --git a/arch/riscv/kernel/sys_riscv.c b/arch/riscv/kernel/sys_riscv.c > > index 571556bb9261..5d3f2fbeb33c 100644 > > --- a/arch/riscv/kernel/sys_riscv.c > > +++ b/arch/riscv/kernel/sys_riscv.c > > @@ -18,9 +18,6 @@ static long riscv_sys_mmap(unsigned long addr, unsigned long len, > > if (unlikely(offset & (~PAGE_MASK >> page_shift_offset))) > > return -EINVAL; > > > > - if (unlikely((prot & PROT_WRITE) && !(prot & PROT_READ))) > > - return -EINVAL; > > - > > return ksys_mmap_pgoff(addr, len, prot, flags, fd, > > offset >> (PAGE_SHIFT - page_shift_offset)); > > } > > -- > > 2.25.1 > > > > > > _______________________________________________ > > linux-riscv mailing list > > linux-riscv@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-riscv >
On 15/09/2022 18:27, Andrew Bresticker wrote: > On Thu, Sep 15, 2022 at 12:56 PM <Conor.Dooley@microchip.com> wrote: >> >> On 09/09/2022 22:27, Andrew Bresticker wrote: >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >>> >>> Commit 2139619bcad7 ("riscv: mmap with PROT_WRITE but no PROT_READ is >>> invalid") made mmap() return EINVAL if PROT_WRITE was set wihtout >>> PROT_READ with the justification that a write-only PTE is considered a >>> reserved PTE permission bit pattern in the privileged spec. This check >>> is unnecessary since we let VM_WRITE imply VM_READ on RISC-V, and it is >>> inconsistent with other architectures that don't support write-only PTEs, >>> creating a potential software portability issue. Just remove the check >>> altogether and let PROT_WRITE imply PROT_READ as is the case on other >>> architectures. >>> >>> Note that this also allows PROT_WRITE|PROT_EXEC mappings which were >>> disallowed prior to the aforementioned commit; PROT_READ is implied in >>> such mappings as well. >>> >>> Fixes: 2139619bcad7 ("riscv: mmap with PROT_WRITE but no PROT_READ is invalid") >> >> For the naive members of the audience such as myself, this patch >> came after a non-fixes patch in the series. What is the dependence >> of this patch on the other one (if any)? > > This patch is dependent on the first. Happy to re-spin with a "Fixes" > tag on the first patch (or maybe Palmer can add when applying). If it is a fix, then it should have a fixes tag. If it's cosmetic reorg to make the fix easier then no & it should be moved after the fix. If it is neither then you should prob mention it in the cover or under the --- /shrug Thanks, Conor. >>> Reviewed-by: Atish Patra <atishp@rivosinc.com> >>> Signed-off-by: Andrew Bresticker <abrestic@rivosinc.com> >>> --- >>> v1 -> v2: Update access_error() to account for write-implies-read >>> v2 -> v3: Separate into two commits >>> --- >>> arch/riscv/kernel/sys_riscv.c | 3 --- >>> 1 file changed, 3 deletions(-) >>> >>> diff --git a/arch/riscv/kernel/sys_riscv.c b/arch/riscv/kernel/sys_riscv.c >>> index 571556bb9261..5d3f2fbeb33c 100644 >>> --- a/arch/riscv/kernel/sys_riscv.c >>> +++ b/arch/riscv/kernel/sys_riscv.c >>> @@ -18,9 +18,6 @@ static long riscv_sys_mmap(unsigned long addr, unsigned long len, >>> if (unlikely(offset & (~PAGE_MASK >> page_shift_offset))) >>> return -EINVAL; >>> >>> - if (unlikely((prot & PROT_WRITE) && !(prot & PROT_READ))) >>> - return -EINVAL; >>> - >>> return ksys_mmap_pgoff(addr, len, prot, flags, fd, >>> offset >> (PAGE_SHIFT - page_shift_offset)); >>> } >>> -- >>> 2.25.1 >>> >>> >>> _______________________________________________ >>> linux-riscv mailing list >>> linux-riscv@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/linux-riscv >>
On 9/16/22 01:40, Conor.Dooley@microchip.com wrote: > On 15/09/2022 18:27, Andrew Bresticker wrote: >> On Thu, Sep 15, 2022 at 12:56 PM <Conor.Dooley@microchip.com> wrote: >>> On 09/09/2022 22:27, Andrew Bresticker wrote: >>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >>>> >>>> Commit 2139619bcad7 ("riscv: mmap with PROT_WRITE but no PROT_READ is >>>> invalid") made mmap() return EINVAL if PROT_WRITE was set wihtout >>>> PROT_READ with the justification that a write-only PTE is considered a >>>> reserved PTE permission bit pattern in the privileged spec. This check >>>> is unnecessary since we let VM_WRITE imply VM_READ on RISC-V, and it is >>>> inconsistent with other architectures that don't support write-only PTEs, >>>> creating a potential software portability issue. Just remove the check >>>> altogether and let PROT_WRITE imply PROT_READ as is the case on other >>>> architectures. >>>> >>>> Note that this also allows PROT_WRITE|PROT_EXEC mappings which were >>>> disallowed prior to the aforementioned commit; PROT_READ is implied in >>>> such mappings as well. >>>> >>>> Fixes: 2139619bcad7 ("riscv: mmap with PROT_WRITE but no PROT_READ is invalid") >>> For the naive members of the audience such as myself, this patch >>> came after a non-fixes patch in the series. What is the dependence >>> of this patch on the other one (if any)? >> This patch is dependent on the first. Happy to re-spin with a "Fixes" >> tag on the first patch (or maybe Palmer can add when applying). > If it is a fix, then it should have a fixes tag. If it's cosmetic reorg > to make the fix easier then no & it should be moved after the fix. If > it is neither then you should prob mention it in the cover or under the > --- /shrug Basically what happens fixes-wise is that patch 1 fixes the original problem in a different way, and patch 2 undoes the previous patch (with small additional fixes). IMO this needs a cover to explain what's going on to those who missed the v1 and v2 discussion thread. v1 here: https://lore.kernel.org/all/20220908170133.1159747-1-abrestic@rivosinc.com Thanks, dram > Thanks, > Conor. > >>>> Reviewed-by: Atish Patra <atishp@rivosinc.com> >>>> Signed-off-by: Andrew Bresticker <abrestic@rivosinc.com> >>>> --- >>>> v1 -> v2: Update access_error() to account for write-implies-read >>>> v2 -> v3: Separate into two commits >>>> --- >>>> arch/riscv/kernel/sys_riscv.c | 3 --- >>>> 1 file changed, 3 deletions(-) >>>> >>>> diff --git a/arch/riscv/kernel/sys_riscv.c b/arch/riscv/kernel/sys_riscv.c >>>> index 571556bb9261..5d3f2fbeb33c 100644 >>>> --- a/arch/riscv/kernel/sys_riscv.c >>>> +++ b/arch/riscv/kernel/sys_riscv.c >>>> @@ -18,9 +18,6 @@ static long riscv_sys_mmap(unsigned long addr, unsigned long len, >>>> if (unlikely(offset & (~PAGE_MASK >> page_shift_offset))) >>>> return -EINVAL; >>>> >>>> - if (unlikely((prot & PROT_WRITE) && !(prot & PROT_READ))) >>>> - return -EINVAL; >>>> - >>>> return ksys_mmap_pgoff(addr, len, prot, flags, fd, >>>> offset >> (PAGE_SHIFT - page_shift_offset)); >>>> } >>>> -- >>>> 2.25.1 >>>> >>>> >>>> _______________________________________________ >>>> linux-riscv mailing list >>>> linux-riscv@lists.infradead.org >>>> http://lists.infradead.org/mailman/listinfo/linux-riscv
diff --git a/arch/riscv/kernel/sys_riscv.c b/arch/riscv/kernel/sys_riscv.c index 571556bb9261..5d3f2fbeb33c 100644 --- a/arch/riscv/kernel/sys_riscv.c +++ b/arch/riscv/kernel/sys_riscv.c @@ -18,9 +18,6 @@ static long riscv_sys_mmap(unsigned long addr, unsigned long len, if (unlikely(offset & (~PAGE_MASK >> page_shift_offset))) return -EINVAL; - if (unlikely((prot & PROT_WRITE) && !(prot & PROT_READ))) - return -EINVAL; - return ksys_mmap_pgoff(addr, len, prot, flags, fd, offset >> (PAGE_SHIFT - page_shift_offset)); }
Commit 2139619bcad7 ("riscv: mmap with PROT_WRITE but no PROT_READ is invalid") made mmap() return EINVAL if PROT_WRITE was set wihtout PROT_READ with the justification that a write-only PTE is considered a reserved PTE permission bit pattern in the privileged spec. This check is unnecessary since we let VM_WRITE imply VM_READ on RISC-V, and it is inconsistent with other architectures that don't support write-only PTEs, creating a potential software portability issue. Just remove the check altogether and let PROT_WRITE imply PROT_READ as is the case on other architectures. Note that this also allows PROT_WRITE|PROT_EXEC mappings which were disallowed prior to the aforementioned commit; PROT_READ is implied in such mappings as well. Fixes: 2139619bcad7 ("riscv: mmap with PROT_WRITE but no PROT_READ is invalid") Reviewed-by: Atish Patra <atishp@rivosinc.com> Signed-off-by: Andrew Bresticker <abrestic@rivosinc.com> --- v1 -> v2: Update access_error() to account for write-implies-read v2 -> v3: Separate into two commits --- arch/riscv/kernel/sys_riscv.c | 3 --- 1 file changed, 3 deletions(-)