linux-riscv.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Celeste Liu <coelacanthushex@gmail.com>
To: "Björn Töpel" <bjorn@kernel.org>,
	"Palmer Dabbelt" <palmer@rivosinc.com>,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"Albert Ou" <aou@eecs.berkeley.edu>,
	"Guo Ren" <guoren@kernel.org>, "Björn Töpel" <bjorn@rivosinc.com>,
	"Conor Dooley" <conor.dooley@microchip.com>,
	linux-riscv@lists.infradead.org
Cc: linux-kernel@vger.kernel.org,
	Felix Yan <felixonmars@archlinux.org>,
	Ruizhe Pan <c141028@gmail.com>,
	Shiqi Zhang <shiqi@isrc.iscas.ac.cn>
Subject: Re: [PATCH v2] riscv: entry: set a0 prior to syscall_enter_from_user_mode
Date: Wed, 19 Jul 2023 04:48:02 +0800	[thread overview]
Message-ID: <cd53e03b-c574-dc05-f9c0-1c8271c5a607@gmail.com> (raw)
In-Reply-To: <03206759-8d6a-a410-a8f9-d4678236bdbf@gmail.com>


On 2023/7/19 04:35, Celeste Liu wrote:
> 
> On 2023/7/19 03:35, Björn Töpel wrote:
>> Celeste Liu <coelacanthushex@gmail.com> writes:
>>
>>> When we test seccomp with 6.4 kernel, we found errno has wrong value.
>>> If we deny NETLINK_AUDIT with EAFNOSUPPORT, after f0bddf50586d, we will
>>> get ENOSYS instead. We got same result with 9c2598d43510 ("riscv: entry: Save a0
>>> prior syscall_enter_from_user_mode()").
>>>
>>> After analysing code, we think that regs->a0 = -ENOSYS should be advanced before
>>> syscall_enter_from_user_mode to fix this problem. In __seccomp_filter, when
>>> seccomp rejected this syscall with specified errno, they will set a0 to return
>>> number as syscall ABI, and then return -1. This return number is finally pass
>>> as return number of syscall_enter_from_user_mode, and then is compared
>>> with NR_syscalls after converted to ulong (so it will be ULONG_MAX).
>>> The condition syscall < NR_syscalls will always be false, so regs->a0 = -ENOSYS
>>> is always executable. It covered a0 set by seccomp, so we always get
>>> ENOSYS when match seccomp RET_ERRNO rule.
>>
>> Isn't something like...
>>
>> diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c
>> index f910dfccbf5d..15a8b4898a6c 100644
>> --- a/arch/riscv/kernel/traps.c
>> +++ b/arch/riscv/kernel/traps.c
>> @@ -297,7 +297,7 @@ asmlinkage __visible __trap_section void do_trap_break(struct pt_regs *regs)
>>  asmlinkage __visible __trap_section void do_trap_ecall_u(struct pt_regs *regs)
>>  {
>>  	if (user_mode(regs)) {
>> -		ulong syscall = regs->a7;
>> +		long syscall = regs->a7;
>>  
>>  		regs->epc += 4;
>>  		regs->orig_a0 = regs->a0;
>> @@ -306,7 +306,7 @@ asmlinkage __visible __trap_section void do_trap_ecall_u(struct pt_regs *regs)
>>  
>>  		syscall = syscall_enter_from_user_mode(regs, syscall);
>>  
>> -		if (syscall < NR_syscalls)
>> +		if (syscall > -1 && syscall < NR_syscalls)
>>  			syscall_handler(regs, syscall);
>>  		else
>>  			regs->a0 = -ENOSYS;
>>
>>
>> ...easier to read?
>>
>>
>> Björn
> 
> It seems that your change turn it back to the beginning. If syscall == -1,
> it is supposed to go neither first nor else branch. It should do NOTHING.
> However it was still a great idea. It may be better to use a set of if-statement
> to clarify the logic.
> 
> diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c
> index f910dfccbf5d2..d0bd725244594 100644
> --- a/arch/riscv/kernel/traps.c
> +++ b/arch/riscv/kernel/traps.c
> @@ -306,7 +306,9 @@ asmlinkage __visible __trap_section void do_trap_ecall_u(struct pt_regs *regs)
>  
>  		syscall = syscall_enter_from_user_mode(regs, syscall);
>  
> -		if (syscall < NR_syscalls)
> +		if (syscall == -1)
> +			// Do nothing
> +		else if (syscall < NR_syscalls)
>  			syscall_handler(regs, syscall);
>  		else
>  			regs->a0 = -ENOSYS;
> 

Oh, it's better to reorder to:

diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c
index f910dfccbf5d2..932814e34ac37 100644
--- a/arch/riscv/kernel/traps.c
+++ b/arch/riscv/kernel/traps.c
@@ -308,7 +308,7 @@ asmlinkage __visible __trap_section void do_trap_ecall_u(struct pt_regs *regs)
 
 		if (syscall < NR_syscalls)
 			syscall_handler(regs, syscall);
-		else
+		else if (syscall != -1)
 			regs->a0 = -ENOSYS;
 
 		syscall_exit_to_user_mode(regs);


I will send v3 later.

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

  reply	other threads:[~2023-07-19  6:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-18 16:28 [PATCH v2] riscv: entry: set a0 prior to syscall_enter_from_user_mode Celeste Liu
2023-07-18 19:35 ` Björn Töpel
2023-07-18 20:35   ` Celeste Liu
2023-07-18 20:48     ` Celeste Liu [this message]
2023-07-18 20:50     ` Björn Töpel
2023-07-18 20:56       ` Celeste Liu

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=cd53e03b-c574-dc05-f9c0-1c8271c5a607@gmail.com \
    --to=coelacanthushex@gmail.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=bjorn@kernel.org \
    --cc=bjorn@rivosinc.com \
    --cc=c141028@gmail.com \
    --cc=conor.dooley@microchip.com \
    --cc=felixonmars@archlinux.org \
    --cc=guoren@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@rivosinc.com \
    --cc=paul.walmsley@sifive.com \
    --cc=shiqi@isrc.iscas.ac.cn \
    /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;
as well as URLs for NNTP newsgroup(s).