All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Szabolcs Nagy <szabolcs.nagy@arm.com>
Cc: linux-api@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: linux interprets an fcntl int arg as long
Date: Mon, 31 Oct 2022 21:46:53 -0400	[thread overview]
Message-ID: <Y2B6jcLUJ1F2y2yL@mit.edu> (raw)
In-Reply-To: <Y1/DS6uoWP7OSkmd@arm.com>

On Mon, Oct 31, 2022 at 12:44:59PM +0000, Szabolcs Nagy wrote:
> and such fcntl call can happen with c code that just passes
> F_SEAL_WRITE since it is an int and e.g. with aarch64 pcs rules
> it is passed in a register where top bits can be non-zero
> (unlikely in practice but valid).

In Linux's aarch64 ABI, an int is a 4-byte value.  It is *not* an
8-byte value.  So passing in "F_SEAL_WRITE | 0xF00000000" as an int
(as in your example) is simply not valid thing for the userspace
program to do.

Now, if there is a C program which has "int c = F_SEAL_WRITE", if the
PCS allows the compiler to pass a function paramter c --- for example
f(a, b, c) --- where the 4-byte paramter 'c' is placed in a 64-bit
register where the high bits of the 64-bit register contains non-zero
garbage values, I would argue that this is a bug in the PCS and/or the
compiler.

						- Ted

WARNING: multiple messages have this Message-ID (diff)
From: "Theodore Ts'o" <tytso@mit.edu>
To: Szabolcs Nagy <szabolcs.nagy@arm.com>
Cc: linux-api@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: linux interprets an fcntl int arg as long
Date: Mon, 31 Oct 2022 21:46:53 -0400	[thread overview]
Message-ID: <Y2B6jcLUJ1F2y2yL@mit.edu> (raw)
In-Reply-To: <Y1/DS6uoWP7OSkmd@arm.com>

On Mon, Oct 31, 2022 at 12:44:59PM +0000, Szabolcs Nagy wrote:
> and such fcntl call can happen with c code that just passes
> F_SEAL_WRITE since it is an int and e.g. with aarch64 pcs rules
> it is passed in a register where top bits can be non-zero
> (unlikely in practice but valid).

In Linux's aarch64 ABI, an int is a 4-byte value.  It is *not* an
8-byte value.  So passing in "F_SEAL_WRITE | 0xF00000000" as an int
(as in your example) is simply not valid thing for the userspace
program to do.

Now, if there is a C program which has "int c = F_SEAL_WRITE", if the
PCS allows the compiler to pass a function paramter c --- for example
f(a, b, c) --- where the 4-byte paramter 'c' is placed in a 64-bit
register where the high bits of the 64-bit register contains non-zero
garbage values, I would argue that this is a bug in the PCS and/or the
compiler.

						- Ted

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

  reply	other threads:[~2022-11-01  1:47 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-31 12:44 linux interprets an fcntl int arg as long Szabolcs Nagy
2022-10-31 12:44 ` Szabolcs Nagy
2022-11-01  1:46 ` Theodore Ts'o [this message]
2022-11-01  1:46   ` Theodore Ts'o
2022-11-01  9:11   ` Szabolcs Nagy
2022-11-01  9:11     ` Szabolcs Nagy
2022-11-01 10:02     ` David Laight
2022-11-01 10:02       ` David Laight
2022-11-01 11:44       ` 'Szabolcs Nagy'
2022-11-01 11:44         ` 'Szabolcs Nagy'
2022-11-01 12:19         ` David Laight
2022-11-01 12:19           ` David Laight
2022-11-01 12:49           ` 'Szabolcs Nagy'
2022-11-01 12:49             ` 'Szabolcs Nagy'
2022-11-01 13:12           ` Mark Rutland
2022-11-01 13:12             ` Mark Rutland
2022-11-01 13:29             ` David Laight
2022-11-01 13:29               ` David Laight
2022-11-01 13:35               ` David Laight
2022-11-01 13:35                 ` David Laight

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=Y2B6jcLUJ1F2y2yL@mit.edu \
    --to=tytso@mit.edu \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=szabolcs.nagy@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.