All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Szabolcs Nagy <szabolcs.nagy@arm.com>
Cc: Florian Weimer <fweimer@redhat.com>,
	Yury Norov <yury.norov@gmail.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	"linux-audit/audit-kernel" 
	<reply+ADSN7RXLQ62LNLD2MK5HFHF65GIU3EVBNHHDPMBXHU@reply.github.com>,
	Xiongfeng Wang <wangxiongfeng2@huawei.com>,
	Wang ShaoBo <bobo.shaobowang@huawei.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
	Adam Borowski <kilobyte@angband.pl>,
	Alexander Graf <agraf@suse.de>,
	Alexey Klimov <klimov.linux@gmail.com>,
	Andreas Schwab <schwab@suse.de>,
	Andrew Pinski <pinskia@gmail.com>,
	Bamvor Zhangjian <bamv2005@gmail.com>,
	Chris Metcalf <cmetcalf@mellanox.com>,
	Christoph Muellner <christoph.muellner@theobroma-systems.com>,
	Dave Martin <Dave.Martin@arm.com>,
	"David S . Miller" <davem@davemloft.net>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	James Hogan <james.hogan@imgtec.com>,
	James Morse <james.morse@arm.com>,
	Joseph Myers <joseph@codesourcery.com>,
	Lin Yongting <linyongting@huawei.com>,
	Manuel Montezelo <manuel.montezelo@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org>,
	Nathan_Lynch <Nathan_Lynch@mentor.com>,
	Philipp Tomsich <philipp.tomsich@theobroma-systems.com>,
	Prasun Kapoor <Prasun.Kapoor@caviumnetworks.com>,
	Ramana Radhakrishnan <ramana.gcc@googlemail.com>,
	Steve Ellcey <sellcey@caviumnetworks.com>
Subject: Re: [linux-audit/audit-kernel] BUG: audit_classify_syscall() fails to properly handle 64-bit syscalls when executing as 32-bit application on ARM (#131)
Date: Mon, 5 Jul 2021 13:55:06 +0200	[thread overview]
Message-ID: <CAK8P3a1D-NvZ2Z8r3RnxKVoT7yPnnqN-ZLrMa9UM13y8==OK6A@mail.gmail.com> (raw)
In-Reply-To: <20210705093656.GJ14854@arm.com>

On Mon, Jul 5, 2021 at 11:36 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> The 07/02/2021 20:19, Florian Weimer wrote:
> > * Yury Norov:
> > > At least Marvell, Samsung, Huawei, Cisco and Weiyuchen's employer
> > > actively use and develop arm64/ilp32. I receive feedback / bugrepotrs
> > > on ilp32 every 4-6 month. Is that enough for you to reconsider
> > > including the project into the mainline?
> >
> > I believe that glibc has the infrastructure now to integrate an ILP32
> > port fairly cleanly, although given that it would be first
> > post-libpthread work, it would have to absorb some of the cleanup work
> > for such a configuration.
>
> time64 would require syscall abi design changes.
> (that's likely an abi break compared to what the
> listed users do)

The kernel port uses the generic syscall ABI, and has done so from the start,
so both time32 and time64 syscalls are supported in principle, as they are
on any other 32-bit architecture these days (except rv32, which dropped
the time32 variant, and x32, which uses the time64 calling conventions but
the time32 syscall names).

       Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Szabolcs Nagy <szabolcs.nagy@arm.com>
Cc: Florian Weimer <fweimer@redhat.com>,
	Yury Norov <yury.norov@gmail.com>,
	 Catalin Marinas <catalin.marinas@arm.com>,
	"linux-audit/audit-kernel"
	<reply+ADSN7RXLQ62LNLD2MK5HFHF65GIU3EVBNHHDPMBXHU@reply.github.com>,
	 Xiongfeng Wang <wangxiongfeng2@huawei.com>,
	Wang ShaoBo <bobo.shaobowang@huawei.com>,
	 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	 "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	 "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	 "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	 "linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
	Adam Borowski <kilobyte@angband.pl>,
	 Alexander Graf <agraf@suse.de>,
	Alexey Klimov <klimov.linux@gmail.com>,
	Andreas Schwab <schwab@suse.de>,
	 Andrew Pinski <pinskia@gmail.com>,
	Bamvor Zhangjian <bamv2005@gmail.com>,
	 Chris Metcalf <cmetcalf@mellanox.com>,
	 Christoph Muellner <christoph.muellner@theobroma-systems.com>,
	 Dave Martin <Dave.Martin@arm.com>,
	"David S . Miller" <davem@davemloft.net>,
	 Geert Uytterhoeven <geert@linux-m68k.org>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	 James Hogan <james.hogan@imgtec.com>,
	James Morse <james.morse@arm.com>,
	 Joseph Myers <joseph@codesourcery.com>,
	Lin Yongting <linyongting@huawei.com>,
	 Manuel Montezelo <manuel.montezelo@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org>,
	 Nathan_Lynch <Nathan_Lynch@mentor.com>,
	 Philipp Tomsich <philipp.tomsich@theobroma-systems.com>,
	 Prasun Kapoor <Prasun.Kapoor@caviumnetworks.com>,
	 Ramana Radhakrishnan <ramana.gcc@googlemail.com>,
	Steve Ellcey <sellcey@caviumnetworks.com>
Subject: Re: [linux-audit/audit-kernel] BUG: audit_classify_syscall() fails to properly handle 64-bit syscalls when executing as 32-bit application on ARM (#131)
Date: Mon, 5 Jul 2021 13:55:06 +0200	[thread overview]
Message-ID: <CAK8P3a1D-NvZ2Z8r3RnxKVoT7yPnnqN-ZLrMa9UM13y8==OK6A@mail.gmail.com> (raw)
In-Reply-To: <20210705093656.GJ14854@arm.com>

On Mon, Jul 5, 2021 at 11:36 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> The 07/02/2021 20:19, Florian Weimer wrote:
> > * Yury Norov:
> > > At least Marvell, Samsung, Huawei, Cisco and Weiyuchen's employer
> > > actively use and develop arm64/ilp32. I receive feedback / bugrepotrs
> > > on ilp32 every 4-6 month. Is that enough for you to reconsider
> > > including the project into the mainline?
> >
> > I believe that glibc has the infrastructure now to integrate an ILP32
> > port fairly cleanly, although given that it would be first
> > post-libpthread work, it would have to absorb some of the cleanup work
> > for such a configuration.
>
> time64 would require syscall abi design changes.
> (that's likely an abi break compared to what the
> listed users do)

The kernel port uses the generic syscall ABI, and has done so from the start,
so both time32 and time64 syscalls are supported in principle, as they are
on any other 32-bit architecture these days (except rv32, which dropped
the time32 variant, and x32, which uses the time64 calling conventions but
the time32 syscall names).

       Arnd

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

  reply	other threads:[~2021-07-05 11:55 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <linux-audit/audit-kernel/issues/131@github.com>
     [not found] ` <linux-audit/audit-kernel/issues/131/872191450@github.com>
2021-07-02 18:07   ` [linux-audit/audit-kernel] BUG: audit_classify_syscall() fails to properly handle 64-bit syscalls when executing as 32-bit application on ARM (#131) Yury Norov
2021-07-02 18:07     ` Yury Norov
2021-07-02 18:19     ` Florian Weimer
2021-07-02 18:19       ` Florian Weimer
2021-07-05  9:36       ` Szabolcs Nagy
2021-07-05  9:36         ` Szabolcs Nagy
2021-07-05 11:55         ` Arnd Bergmann [this message]
2021-07-05 11:55           ` Arnd Bergmann
2021-07-05 12:09           ` Szabolcs Nagy
2021-07-05 12:09             ` Szabolcs Nagy
2021-07-05 10:48     ` Andreas Schwab
2021-07-05 10:48       ` Andreas Schwab
2021-07-07 18:44       ` Yury Norov
2021-07-07 18:44         ` Yury Norov
2021-07-07 18:54         ` Paul Moore
2021-07-07 18:54           ` Paul Moore
2021-07-05 13:40     ` Arnd Bergmann
2021-07-05 13:40       ` Arnd Bergmann

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='CAK8P3a1D-NvZ2Z8r3RnxKVoT7yPnnqN-ZLrMa9UM13y8==OK6A@mail.gmail.com' \
    --to=arnd@arndb.de \
    --cc=Dave.Martin@arm.com \
    --cc=Nathan_Lynch@mentor.com \
    --cc=Prasun.Kapoor@caviumnetworks.com \
    --cc=agraf@suse.de \
    --cc=bamv2005@gmail.com \
    --cc=bobo.shaobowang@huawei.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=christoph.muellner@theobroma-systems.com \
    --cc=cmetcalf@mellanox.com \
    --cc=davem@davemloft.net \
    --cc=fweimer@redhat.com \
    --cc=geert@linux-m68k.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=james.hogan@imgtec.com \
    --cc=james.morse@arm.com \
    --cc=joseph@codesourcery.com \
    --cc=kilobyte@angband.pl \
    --cc=klimov.linux@gmail.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linyongting@huawei.com \
    --cc=manuel.montezelo@gmail.com \
    --cc=maxim.kuvyrkov@linaro.org \
    --cc=philipp.tomsich@theobroma-systems.com \
    --cc=pinskia@gmail.com \
    --cc=ramana.gcc@googlemail.com \
    --cc=reply+ADSN7RXLQ62LNLD2MK5HFHF65GIU3EVBNHHDPMBXHU@reply.github.com \
    --cc=schwab@suse.de \
    --cc=schwidefsky@de.ibm.com \
    --cc=sellcey@caviumnetworks.com \
    --cc=szabolcs.nagy@arm.com \
    --cc=wangxiongfeng2@huawei.com \
    --cc=yury.norov@gmail.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.