All of lore.kernel.org
 help / color / mirror / Atom feed
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: linaro-kernel@lists.linaro.org, rgb@redhat.com,
	will.deacon@arm.com, linux-kernel@vger.kernel.org,
	eparis@redhat.com, dsaxena@linaro.org, viro@zeniv.linux.org.uk,
	linux-audit@redhat.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm: prevent BUG_ON in audit_syscall_entry()
Date: Tue, 09 Sep 2014 13:48:51 +0900	[thread overview]
Message-ID: <540E86B3.7080700@linaro.org> (raw)
In-Reply-To: <20140905095252.GF30401@n2100.arm.linux.org.uk>

Russell,

On 09/05/2014 06:52 PM, Russell King - ARM Linux wrote:
> On Fri, Sep 05, 2014 at 06:46:33PM +0900, AKASHI Takahiro wrote:
>> BUG_ON() in audit_syscall_entry() will be hit if user issues syscall(-1)
>> while syscall auditing is enabled (that is, by starting auditd).
>> In fact, syscall(-1) just fails (not signaled despite the expectation,
>> this is another minor bug), but the succeeding syscall hits BUG_ON.
>>
>> When auditing syscall(-1), audit_syscall_entry() is called anyway, but
>> audit_syscall_exit() is not called and then 'in_syscall' flag in thread's
>> audit context is kept on. In this way, audit_syscall_entry() against
>> the succeeding syscall will see BUG_ON(in_syscall).
>>
>> This patch fixes this bug by
>> 1) enforcing syscall exit tracing, including audit_syscall_exit(), to be
>>     executed in all cases,
>
> Really, no.  That adds additional overhead to every syscall, and that
> matters for system performance.  We want to have as little as possible
> overhead here.

My words might have confused you, but this issue exists, in the current
mainline kernel, not only against syscall(-1), but any invalid or pseudo syscalls.
(And other archs seem to behave in the same way AFAIK.)
But if you want, I can fix it.
See my next version.

-Takahiro AKASHI

> The second issue here is that you haven't explained where the oops
> occurs.  It's seen as a good practice to include the oops dump for the
> bug you're fixing in the commit changelog, so that others can see the
> starting point for the investigation, and see exactly where things are
> going wrong.
>

WARNING: multiple messages have this Message-ID (diff)
From: takahiro.akashi@linaro.org (AKASHI Takahiro)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm: prevent BUG_ON in audit_syscall_entry()
Date: Tue, 09 Sep 2014 13:48:51 +0900	[thread overview]
Message-ID: <540E86B3.7080700@linaro.org> (raw)
In-Reply-To: <20140905095252.GF30401@n2100.arm.linux.org.uk>

Russell,

On 09/05/2014 06:52 PM, Russell King - ARM Linux wrote:
> On Fri, Sep 05, 2014 at 06:46:33PM +0900, AKASHI Takahiro wrote:
>> BUG_ON() in audit_syscall_entry() will be hit if user issues syscall(-1)
>> while syscall auditing is enabled (that is, by starting auditd).
>> In fact, syscall(-1) just fails (not signaled despite the expectation,
>> this is another minor bug), but the succeeding syscall hits BUG_ON.
>>
>> When auditing syscall(-1), audit_syscall_entry() is called anyway, but
>> audit_syscall_exit() is not called and then 'in_syscall' flag in thread's
>> audit context is kept on. In this way, audit_syscall_entry() against
>> the succeeding syscall will see BUG_ON(in_syscall).
>>
>> This patch fixes this bug by
>> 1) enforcing syscall exit tracing, including audit_syscall_exit(), to be
>>     executed in all cases,
>
> Really, no.  That adds additional overhead to every syscall, and that
> matters for system performance.  We want to have as little as possible
> overhead here.

My words might have confused you, but this issue exists, in the current
mainline kernel, not only against syscall(-1), but any invalid or pseudo syscalls.
(And other archs seem to behave in the same way AFAIK.)
But if you want, I can fix it.
See my next version.

-Takahiro AKASHI

> The second issue here is that you haven't explained where the oops
> occurs.  It's seen as a good practice to include the oops dump for the
> bug you're fixing in the commit changelog, so that others can see the
> starting point for the investigation, and see exactly where things are
> going wrong.
>

WARNING: multiple messages have this Message-ID (diff)
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: will.deacon@arm.com, viro@zeniv.linux.org.uk, eparis@redhat.com,
	rgb@redhat.com, dsaxena@linaro.org,
	linux-arm-kernel@lists.infradead.org,
	linaro-kernel@lists.linaro.org, linux-kernel@vger.kernel.org,
	linux-audit@redhat.com
Subject: Re: [PATCH] arm: prevent BUG_ON in audit_syscall_entry()
Date: Tue, 09 Sep 2014 13:48:51 +0900	[thread overview]
Message-ID: <540E86B3.7080700@linaro.org> (raw)
In-Reply-To: <20140905095252.GF30401@n2100.arm.linux.org.uk>

Russell,

On 09/05/2014 06:52 PM, Russell King - ARM Linux wrote:
> On Fri, Sep 05, 2014 at 06:46:33PM +0900, AKASHI Takahiro wrote:
>> BUG_ON() in audit_syscall_entry() will be hit if user issues syscall(-1)
>> while syscall auditing is enabled (that is, by starting auditd).
>> In fact, syscall(-1) just fails (not signaled despite the expectation,
>> this is another minor bug), but the succeeding syscall hits BUG_ON.
>>
>> When auditing syscall(-1), audit_syscall_entry() is called anyway, but
>> audit_syscall_exit() is not called and then 'in_syscall' flag in thread's
>> audit context is kept on. In this way, audit_syscall_entry() against
>> the succeeding syscall will see BUG_ON(in_syscall).
>>
>> This patch fixes this bug by
>> 1) enforcing syscall exit tracing, including audit_syscall_exit(), to be
>>     executed in all cases,
>
> Really, no.  That adds additional overhead to every syscall, and that
> matters for system performance.  We want to have as little as possible
> overhead here.

My words might have confused you, but this issue exists, in the current
mainline kernel, not only against syscall(-1), but any invalid or pseudo syscalls.
(And other archs seem to behave in the same way AFAIK.)
But if you want, I can fix it.
See my next version.

-Takahiro AKASHI

> The second issue here is that you haven't explained where the oops
> occurs.  It's seen as a good practice to include the oops dump for the
> bug you're fixing in the commit changelog, so that others can see the
> starting point for the investigation, and see exactly where things are
> going wrong.
>

  reply	other threads:[~2014-09-09  4:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-05  9:46 [PATCH] arm: prevent BUG_ON in audit_syscall_entry() AKASHI Takahiro
2014-09-05  9:46 ` AKASHI Takahiro
2014-09-05  9:52 ` Russell King - ARM Linux
2014-09-05  9:52   ` Russell King - ARM Linux
2014-09-09  4:48   ` AKASHI Takahiro [this message]
2014-09-09  4:48     ` AKASHI Takahiro
2014-09-09  4:48     ` AKASHI Takahiro

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=540E86B3.7080700@linaro.org \
    --to=takahiro.akashi@linaro.org \
    --cc=dsaxena@linaro.org \
    --cc=eparis@redhat.com \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-audit@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=rgb@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=will.deacon@arm.com \
    /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.