All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kefeng Wang <wangkefeng.wang@huawei.com>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: <linux-arm-kernel@lists.infradead.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	<linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jungseung Lee <js07.lee@gmail.com>
Subject: Re: [PATCH v2 7/7] ARM: mm: Fix PXN process with LPAE feature
Date: Mon, 7 Jun 2021 16:32:55 +0800	[thread overview]
Message-ID: <f2f533fb-ab11-f76c-85b7-20a9196c24fd@huawei.com> (raw)
In-Reply-To: <c9c4a8ec-da51-4de9-4404-b5bf7f017441@huawei.com>

Hi Russell,  any comments, thanks.

On 2021/6/3 17:38, Kefeng Wang wrote:
>
> On 2021/6/2 23:58, Russell King (Oracle) wrote:
>> On Wed, Jun 02, 2021 at 11:13:14PM +0800, Kefeng Wang wrote:
>>>    IFSR format when using the Short-descriptor translation table format
>>>
>>>      Domain fault      01001            First level   01011     
>>> Second level
>>>
>>>      Permission fault 01101            First level   01111 Second level
>>>
>>>    IFSR format when using the Long-descriptor translation table format
>>>
>>>     0011LL Permission fault. LL bits indicate levelb.
>>>
>>> After check the ARM spec, I think for the permission fault, we 
>>> should panic
>>> with or without LPAE, will change to
>> As I explained in one of the previous patches, the page tables that get
>> used for mapping kernel space are the _tasks_ own page tables. Any new
>> kernel mappings are lazily copied to the task page tables - such as
>> when a module is loaded.
>>
>> The first time we touch a page, we could end up with a page translation
>> fault. This will call do_page_fault(), and so with your proposal,
>> loading a module will potentially cause a kernel panic in this case,
>> probably leading to systems that panic early during userspace boot.
>
> Could we add some FSR_FS check, only panic when the permission fault, 
> eg,
>
> +static inline bool is_permission_fault(unsigned int fsr)
> +{
> +       int fs = fsr_fs(fsr);
> +#ifdef CONFIG_ARM_LPAE
> +       if ((fs & FS_PERM_NOLL_MASK) == FS_PERM_NOLL)
> +               return true;
> +#else
> +       if (fs == FS_L1_PERM || fs == FS_L2_PERM )
> +               return true;
> +#endif
> +       return false;
> +}
> +
>  static int __kprobes
>  do_page_fault(unsigned long addr, unsigned int fsr, struct pt_regs 
> *regs)
>  {
> @@ -255,8 +268,7 @@ do_page_fault(unsigned long addr, unsigned int 
> fsr, struct pt_regs *regs)
>
>         if (fsr & FSR_LNX_PF) {
>                 vm_flags = VM_EXEC;
> -
> -               if (!user_mode(regs))
> +               if (is_permission_fault && !user_mode(regs))
>                         die_kernel_fault("execution of memory",
>                                          mm, addr, fsr, regs);
>         }
>
> diff --git a/arch/arm/mm/fault.h b/arch/arm/mm/fault.h
> index 9ecc2097a87a..187954b4acca 100644
> --- a/arch/arm/mm/fault.h
> +++ b/arch/arm/mm/fault.h
> @@ -14,6 +14,8 @@
>
>  #ifdef CONFIG_ARM_LPAE
>  #define FSR_FS_AEA             17
> +#define FS_PERM_NOLL           0xC
> +#define FS_PERM_NOLL_MASK      0x3C
>
>  static inline int fsr_fs(unsigned int fsr)
>  {
> @@ -21,6 +23,8 @@ static inline int fsr_fs(unsigned int fsr)
>  }
>  #else
>  #define FSR_FS_AEA             22
> +#define FS_L1_PERM             0xD
> +#define FS_L2_PERM             0xF
>
> and suggestion or proper solution to solve the issue?
>
>>

WARNING: multiple messages have this Message-ID (diff)
From: Kefeng Wang <wangkefeng.wang@huawei.com>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: <linux-arm-kernel@lists.infradead.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	<linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jungseung Lee <js07.lee@gmail.com>
Subject: Re: [PATCH v2 7/7] ARM: mm: Fix PXN process with LPAE feature
Date: Mon, 7 Jun 2021 16:32:55 +0800	[thread overview]
Message-ID: <f2f533fb-ab11-f76c-85b7-20a9196c24fd@huawei.com> (raw)
In-Reply-To: <c9c4a8ec-da51-4de9-4404-b5bf7f017441@huawei.com>

Hi Russell,  any comments, thanks.

On 2021/6/3 17:38, Kefeng Wang wrote:
>
> On 2021/6/2 23:58, Russell King (Oracle) wrote:
>> On Wed, Jun 02, 2021 at 11:13:14PM +0800, Kefeng Wang wrote:
>>>    IFSR format when using the Short-descriptor translation table format
>>>
>>>      Domain fault      01001            First level   01011     
>>> Second level
>>>
>>>      Permission fault 01101            First level   01111 Second level
>>>
>>>    IFSR format when using the Long-descriptor translation table format
>>>
>>>     0011LL Permission fault. LL bits indicate levelb.
>>>
>>> After check the ARM spec, I think for the permission fault, we 
>>> should panic
>>> with or without LPAE, will change to
>> As I explained in one of the previous patches, the page tables that get
>> used for mapping kernel space are the _tasks_ own page tables. Any new
>> kernel mappings are lazily copied to the task page tables - such as
>> when a module is loaded.
>>
>> The first time we touch a page, we could end up with a page translation
>> fault. This will call do_page_fault(), and so with your proposal,
>> loading a module will potentially cause a kernel panic in this case,
>> probably leading to systems that panic early during userspace boot.
>
> Could we add some FSR_FS check, only panic when the permission fault, 
> eg,
>
> +static inline bool is_permission_fault(unsigned int fsr)
> +{
> +       int fs = fsr_fs(fsr);
> +#ifdef CONFIG_ARM_LPAE
> +       if ((fs & FS_PERM_NOLL_MASK) == FS_PERM_NOLL)
> +               return true;
> +#else
> +       if (fs == FS_L1_PERM || fs == FS_L2_PERM )
> +               return true;
> +#endif
> +       return false;
> +}
> +
>  static int __kprobes
>  do_page_fault(unsigned long addr, unsigned int fsr, struct pt_regs 
> *regs)
>  {
> @@ -255,8 +268,7 @@ do_page_fault(unsigned long addr, unsigned int 
> fsr, struct pt_regs *regs)
>
>         if (fsr & FSR_LNX_PF) {
>                 vm_flags = VM_EXEC;
> -
> -               if (!user_mode(regs))
> +               if (is_permission_fault && !user_mode(regs))
>                         die_kernel_fault("execution of memory",
>                                          mm, addr, fsr, regs);
>         }
>
> diff --git a/arch/arm/mm/fault.h b/arch/arm/mm/fault.h
> index 9ecc2097a87a..187954b4acca 100644
> --- a/arch/arm/mm/fault.h
> +++ b/arch/arm/mm/fault.h
> @@ -14,6 +14,8 @@
>
>  #ifdef CONFIG_ARM_LPAE
>  #define FSR_FS_AEA             17
> +#define FS_PERM_NOLL           0xC
> +#define FS_PERM_NOLL_MASK      0x3C
>
>  static inline int fsr_fs(unsigned int fsr)
>  {
> @@ -21,6 +23,8 @@ static inline int fsr_fs(unsigned int fsr)
>  }
>  #else
>  #define FSR_FS_AEA             22
> +#define FS_L1_PERM             0xD
> +#define FS_L2_PERM             0xF
>
> and suggestion or proper solution to solve the issue?
>
>>

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

  reply	other threads:[~2021-06-07  8:33 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-02  7:02 [PATCH v2 0/7] ARM: mm: cleanup page fault and fix pxn process issue Kefeng Wang
2021-06-02  7:02 ` Kefeng Wang
2021-06-02  7:02 ` [PATCH v2 1/7] ARM: mm: Rafactor the __do_page_fault() Kefeng Wang
2021-06-02  7:02   ` Kefeng Wang
2021-06-02 10:29   ` Russell King (Oracle)
2021-06-02 10:29     ` Russell King (Oracle)
2021-06-02  7:02 ` [PATCH v2 2/7] ARM: mm: Kill task_struct argument for __do_page_fault() Kefeng Wang
2021-06-02  7:02   ` Kefeng Wang
2021-06-02 10:31   ` Russell King (Oracle)
2021-06-02 10:31     ` Russell King (Oracle)
2021-06-02  7:02 ` [PATCH v2 3/7] ARM: mm: Cleanup access_error() Kefeng Wang
2021-06-02  7:02   ` Kefeng Wang
2021-06-02 10:39   ` Russell King (Oracle)
2021-06-02 10:39     ` Russell King (Oracle)
2021-06-02  7:02 ` [PATCH v2 4/7] ARM: mm: print out correct page table entries Kefeng Wang
2021-06-02  7:02   ` Kefeng Wang
2021-06-02 10:44   ` Russell King (Oracle)
2021-06-02 10:44     ` Russell King (Oracle)
2021-06-02 11:24     ` Kefeng Wang
2021-06-02 11:24       ` Kefeng Wang
2021-06-02  7:02 ` [PATCH v2 5/7] ARM: mm: Print physical address of page table base in show_pte() Kefeng Wang
2021-06-02  7:02   ` Kefeng Wang
2021-06-02 10:47   ` Russell King (Oracle)
2021-06-02 10:47     ` Russell King (Oracle)
2021-06-02 11:25     ` Kefeng Wang
2021-06-02 11:25       ` Kefeng Wang
2021-06-02  7:02 ` [PATCH v2 6/7] ARM: mm: Provide die_kernel_fault() helper Kefeng Wang
2021-06-02  7:02   ` Kefeng Wang
2021-06-02 10:49   ` Russell King (Oracle)
2021-06-02 10:49     ` Russell King (Oracle)
2021-06-02  7:02 ` [PATCH v2 7/7] ARM: mm: Fix PXN process with LPAE feature Kefeng Wang
2021-06-02  7:02   ` Kefeng Wang
2021-06-02 10:52   ` Russell King (Oracle)
2021-06-02 10:52     ` Russell King (Oracle)
2021-06-02 15:13     ` Kefeng Wang
2021-06-02 15:13       ` Kefeng Wang
2021-06-02 15:58       ` Russell King (Oracle)
2021-06-02 15:58         ` Russell King (Oracle)
2021-06-03  9:38         ` Kefeng Wang
2021-06-03  9:38           ` Kefeng Wang
2021-06-07  8:32           ` Kefeng Wang [this message]
2021-06-07  8:32             ` Kefeng Wang

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=f2f533fb-ab11-f76c-85b7-20a9196c24fd@huawei.com \
    --to=wangkefeng.wang@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=catalin.marinas@arm.com \
    --cc=js07.lee@gmail.com \
    --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.