All of lore.kernel.org
 help / color / mirror / Atom feed
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: "viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
	"eparis@redhat.com" <eparis@redhat.com>,
	"rgb@redhat.com" <rgb@redhat.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"arndb@arndb.de" <arndb@arndb.de>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linaro-kernel@lists.linaro.org" <linaro-kernel@lists.linaro.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-audit@redhat.com" <linux-audit@redhat.com>,
	"patches@linaro.org" <patches@linaro.org>
Subject: Re: [PATCH v3] audit: Add generic compat syscall support
Date: Wed, 29 Jan 2014 14:58:59 +0900	[thread overview]
Message-ID: <52E898A3.2050401@linaro.org> (raw)
In-Reply-To: <20140127121505.GD32608@arm.com>

Catalin,

Let me correct myself,

On 01/27/2014 09:15 PM, Catalin Marinas wrote:
> On Mon, Jan 27, 2014 at 05:58:07AM +0000, AKASHI Takahiro wrote:
>> Catalin and audit maintainers,
>>
>> On 01/23/2014 11:51 PM, Catalin Marinas wrote:
>>> On Fri, Jan 17, 2014 at 08:03:15AM +0000, AKASHI Takahiro wrote:
>>>> diff --git a/lib/compat_audit.c b/lib/compat_audit.c
>>>> new file mode 100644
>>>> index 0000000..94f6480
>>>> --- /dev/null
>>>> +++ b/lib/compat_audit.c
>>>> @@ -0,0 +1,51 @@
>>>> +#include <linux/init.h>
>>>> +#include <linux/types.h>
>>>> +/* FIXME: this might be architecture dependent */
>>>> +#include <asm/unistd_32.h>
>>>
>>> It most likely is architecture dependent.
>>
>> I'm wondering what name is the most appropriate in this case.
>> Most archictures have __NR_xyz definitions in "unistd_32.h",
>> but arm64 doesn't have it, instead "unistd32." which contains
>> only __SYSCALL(xyz, NO). Confusing?
>
> I don't think we should introduce a new file (or at least it should be
> named something containing "audit" to make it clearer).
>
>>>> +int audit_classify_compat_syscall(int abi, unsigned syscall)
>>>> +{
>>>> +	switch (syscall) {
>>>> +#ifdef __NR_open
>>>> +	case __NR_open:
>>>> +		return 2;
>>>> +#endif
>>>> +#ifdef __NR_openat
>>>> +	case __NR_openat:
>>>> +		return 3;
>>>> +#endif
>>>> +#ifdef __NR_socketcall
>>>> +	case __NR_socketcall:
>>>> +		return 4;
>>>> +#endif
>>>> +	case __NR_execve:
>>>> +		return 5;
>>>> +	default:
>>>> +		return 1;
>>>> +	}
>>>> +}
>>>
>>> BTW, since they aren't many, you could get the arch code to define
>>> __NR_compat_open etc. explicitly and use these. On arm64 we have a few
>>> of these defined to avoid name collision in signal handling code.
>>
>> Again, most architecture have their own unistd32.h for compat system calls,
>> and use __NR_open-like naming.
>> It's unlikely for these archs to migrate to "generic compat" auditing,
>> but I believe that '__NR_open'-like naming is better because we may be able to avoid
>> arch-specific changes even for future(?) syscall-related enhancements in audit.

In my compat_audit.c, all the entries in audit classes are derived from asm-generic/audit_*.h,
where __NR_xyz are used to list the system calls. So it is not possible to use __NR_compat_xyz
as far as we re-use those generic files.
(Obviously we don't want to duplicate those header files, that is, audit_compat_*.h.)

I agree that we should not have similar but different files, like unist32.h and unistd_32.h,
but it seems to be inevitable for our case. (That is the reason why I dynamically generate unistd_32.h)

As for arch-specific header file name, "audit_unistd32.h" can be fine, but people on other architectures
might be unhappy with such a name since they can commonly use unistd32.h instead.


- Takahiro AKASHI

> My preference is as above, a few __NR_compat_* (just those required by
> audit) defined in unistd.h but I'm not an audit maintainer.
>

WARNING: multiple messages have this Message-ID (diff)
From: takahiro.akashi@linaro.org (AKASHI Takahiro)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3] audit: Add generic compat syscall support
Date: Wed, 29 Jan 2014 14:58:59 +0900	[thread overview]
Message-ID: <52E898A3.2050401@linaro.org> (raw)
In-Reply-To: <20140127121505.GD32608@arm.com>

Catalin,

Let me correct myself,

On 01/27/2014 09:15 PM, Catalin Marinas wrote:
> On Mon, Jan 27, 2014 at 05:58:07AM +0000, AKASHI Takahiro wrote:
>> Catalin and audit maintainers,
>>
>> On 01/23/2014 11:51 PM, Catalin Marinas wrote:
>>> On Fri, Jan 17, 2014 at 08:03:15AM +0000, AKASHI Takahiro wrote:
>>>> diff --git a/lib/compat_audit.c b/lib/compat_audit.c
>>>> new file mode 100644
>>>> index 0000000..94f6480
>>>> --- /dev/null
>>>> +++ b/lib/compat_audit.c
>>>> @@ -0,0 +1,51 @@
>>>> +#include <linux/init.h>
>>>> +#include <linux/types.h>
>>>> +/* FIXME: this might be architecture dependent */
>>>> +#include <asm/unistd_32.h>
>>>
>>> It most likely is architecture dependent.
>>
>> I'm wondering what name is the most appropriate in this case.
>> Most archictures have __NR_xyz definitions in "unistd_32.h",
>> but arm64 doesn't have it, instead "unistd32." which contains
>> only __SYSCALL(xyz, NO). Confusing?
>
> I don't think we should introduce a new file (or at least it should be
> named something containing "audit" to make it clearer).
>
>>>> +int audit_classify_compat_syscall(int abi, unsigned syscall)
>>>> +{
>>>> +	switch (syscall) {
>>>> +#ifdef __NR_open
>>>> +	case __NR_open:
>>>> +		return 2;
>>>> +#endif
>>>> +#ifdef __NR_openat
>>>> +	case __NR_openat:
>>>> +		return 3;
>>>> +#endif
>>>> +#ifdef __NR_socketcall
>>>> +	case __NR_socketcall:
>>>> +		return 4;
>>>> +#endif
>>>> +	case __NR_execve:
>>>> +		return 5;
>>>> +	default:
>>>> +		return 1;
>>>> +	}
>>>> +}
>>>
>>> BTW, since they aren't many, you could get the arch code to define
>>> __NR_compat_open etc. explicitly and use these. On arm64 we have a few
>>> of these defined to avoid name collision in signal handling code.
>>
>> Again, most architecture have their own unistd32.h for compat system calls,
>> and use __NR_open-like naming.
>> It's unlikely for these archs to migrate to "generic compat" auditing,
>> but I believe that '__NR_open'-like naming is better because we may be able to avoid
>> arch-specific changes even for future(?) syscall-related enhancements in audit.

In my compat_audit.c, all the entries in audit classes are derived from asm-generic/audit_*.h,
where __NR_xyz are used to list the system calls. So it is not possible to use __NR_compat_xyz
as far as we re-use those generic files.
(Obviously we don't want to duplicate those header files, that is, audit_compat_*.h.)

I agree that we should not have similar but different files, like unist32.h and unistd_32.h,
but it seems to be inevitable for our case. (That is the reason why I dynamically generate unistd_32.h)

As for arch-specific header file name, "audit_unistd32.h" can be fine, but people on other architectures
might be unhappy with such a name since they can commonly use unistd32.h instead.


- Takahiro AKASHI

> My preference is as above, a few __NR_compat_* (just those required by
> audit) defined in unistd.h but I'm not an audit maintainer.
>

  reply	other threads:[~2014-01-29  5:58 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-19  7:33 [RFC PATCH] audit: generic compat system call support AKASHI Takahiro
2013-11-19  7:33 ` [RFC PATCH] audit: Add generic compat syscall support AKASHI Takahiro
2013-11-19  9:43   ` [RFC PATCH v2 1/1] " AKASHI Takahiro
2013-11-25 19:01     ` Will Deacon
2013-11-27  1:34       ` AKASHI Takahiro
2014-01-10 18:36         ` Richard Guy Briggs
2014-01-17  8:03     ` [PATCH v3] audit: generic compat system call support AKASHI Takahiro
2014-01-17  8:03       ` AKASHI Takahiro
2014-01-17  8:03       ` [PATCH v3] audit: Add generic compat syscall support AKASHI Takahiro
2014-01-17  8:03         ` AKASHI Takahiro
2014-01-23 14:51         ` Catalin Marinas
2014-01-23 14:51           ` Catalin Marinas
2014-01-27  5:58           ` AKASHI Takahiro
2014-01-27  5:58             ` AKASHI Takahiro
2014-01-27 12:15             ` Catalin Marinas
2014-01-27 12:15               ` Catalin Marinas
2014-01-29  5:58               ` AKASHI Takahiro [this message]
2014-01-29  5:58                 ` AKASHI Takahiro
2014-01-30 18:07                 ` Catalin Marinas
2014-01-30 18:07                   ` Catalin Marinas
2014-02-03  6:55       ` [PATCH v4 0/1] audit: generic compat system call support AKASHI Takahiro
2014-02-03  6:55         ` AKASHI Takahiro
2014-02-03  6:55         ` [PATCH v4 1/1] audit: Add generic compat syscall support AKASHI Takahiro
2014-02-03  6:55           ` AKASHI Takahiro
2014-03-15  5:47         ` [PATCH_v5] audit: generic compat system call support AKASHI Takahiro
2014-03-15  5:47           ` AKASHI Takahiro
2014-03-15  5:48           ` [PATCH_v5] audit: Add generic compat syscall support AKASHI Takahiro
2014-03-15  5:48             ` AKASHI Takahiro
2014-03-16 19:13             ` Richard Guy Briggs
2014-03-16 19:13               ` Richard Guy Briggs
2013-12-13  8:37   ` [RFC PATCH] " AKASHI Takahiro
  -- strict thread matches above, loose matches on Subject: below --
2014-01-17  8:11 [PATCH v3] audit: generic compat system call support AKASHI Takahiro
2014-01-17  8:11 ` [PATCH v3] audit: Add generic compat syscall support 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=52E898A3.2050401@linaro.org \
    --to=takahiro.akashi@linaro.org \
    --cc=Will.Deacon@arm.com \
    --cc=arndb@arndb.de \
    --cc=catalin.marinas@arm.com \
    --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=patches@linaro.org \
    --cc=rgb@redhat.com \
    --cc=viro@zeniv.linux.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.