Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1262788 > unrolled thread

Re: [PATCH] arm: Use kernel mm when updating section permissions

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] arm: Use kernel mm when updating section permissions Kees Cook <keescook@chromium.org> - 2015-11-05 02:10 +0100
    Re: [PATCH] arm: Use kernel mm when updating section permissions Kees Cook <keescook@chromium.org> - 2015-11-05 02:20 +0100

#1262788 — Re: [PATCH] arm: Use kernel mm when updating section permissions

On Wed, Nov 4, 2015 at 5:00 PM, Laura Abbott <labbott@fedoraproject.org> wrote:
> Currently, read only permissions are not being applied even
> when CONFIG_DEBUG_RODATA is set. This is because section_update
> uses current->mm for adjusting the page tables. current->mm
> need not be equivalent to the kernel version. Use pgd_offset_k
> to get the proper page directory for updating.
>
> Signed-off-by: Laura Abbott <labbott@fedoraproject.org>
> ---
> I found this while trying to convince myself of something.
> Dumping the page table via debugfs and writing to kernel text were both
> showing the lack of mappings. This was observed on QEMU. Maybe it's just a
> QEMUism but if not it probably should go to stable.

Well that's weird! debugfs showed the actual permissions that lacked
RO? I wonder what changed. I tested this both with debugfs and lkdtm's
KERN_WRITE test when the patches originally landed.

-Kees

> ---
>  arch/arm/mm/init.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index 8a63b4c..4bb936a 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -629,11 +629,9 @@ static struct section_perm ro_perms[] = {
>  static inline void section_update(unsigned long addr, pmdval_t mask,
>                                   pmdval_t prot)
>  {
> -       struct mm_struct *mm;
>         pmd_t *pmd;
>
> -       mm = current->active_mm;
> -       pmd = pmd_offset(pud_offset(pgd_offset(mm, addr), addr), addr);
> +       pmd = pmd_offset(pud_offset(pgd_offset_k(addr), addr), addr);
>
>  #ifdef CONFIG_ARM_LPAE
>         pmd[0] = __pmd((pmd_val(pmd[0]) & mask) | prot);
> --
> 2.5.0
>



-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1262792

On Wed, Nov 4, 2015 at 5:06 PM, Kees Cook <keescook@chromium.org> wrote:
> On Wed, Nov 4, 2015 at 5:00 PM, Laura Abbott <labbott@fedoraproject.org> wrote:
>> Currently, read only permissions are not being applied even
>> when CONFIG_DEBUG_RODATA is set. This is because section_update
>> uses current->mm for adjusting the page tables. current->mm
>> need not be equivalent to the kernel version. Use pgd_offset_k
>> to get the proper page directory for updating.
>>
>> Signed-off-by: Laura Abbott <labbott@fedoraproject.org>
>> ---
>> I found this while trying to convince myself of something.
>> Dumping the page table via debugfs and writing to kernel text were both
>> showing the lack of mappings. This was observed on QEMU. Maybe it's just a
>> QEMUism but if not it probably should go to stable.
>
> Well that's weird! debugfs showed the actual permissions that lacked
> RO? I wonder what changed. I tested this both with debugfs and lkdtm's
> KERN_WRITE test when the patches originally landed.

The comment will need adjusting too. I have a memory of needing to use
current->mm to deal with some crazy errata and handling TLB flushes...

-Kees

-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web