linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Szabolcs Nagy <szabolcs.nagy@arm.com>
To: Catalin Marinas <catalin.marinas@arm.com>,
	Alexey Izbyshev <izbyshev@ispras.ru>
Cc: David Hildenbrand <david@redhat.com>,
	Florent Revest <revest@chromium.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	akpm@linux-foundation.org, anshuman.khandual@arm.com,
	joey.gouly@arm.com, mhocko@suse.com, keescook@chromium.org,
	peterx@redhat.com, broonie@kernel.org, kpsingh@kernel.org,
	gthelen@google.com, toiwoton@gmail.com
Subject: Re: [PATCH v2 3/5] mm: Make PR_MDWE_REFUSE_EXEC_GAIN an unsigned long
Date: Tue, 23 May 2023 16:01:24 +0100	[thread overview]
Message-ID: <ZGzVRO7eCsn7sOe1@arm.com> (raw)
In-Reply-To: <ZGzJNvKu8h5nDXsa@arm.com>

The 05/23/2023 15:09, Catalin Marinas wrote:
> At least for glibc, it seems that there is a conversion to unsigned
> long:
>
> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/prctl.c#l28
>
> unsigned long int arg2 = va_arg (arg, unsigned long int);
>
> (does va_arg expand to an actual cast?)

this is not a conversion.

at this point the argument is already corrupt since
an int was passed instead of unsigned long, usually
it's just wrong top 32bit, but in theory arg passing
for int and long could be completely different.

>
> If the libc passes a 32-bit to a kernel ABI that expects 64-bit, I think
> it's a user-space bug and not a kernel ABI issue.

this is point 3 in an earlier mail i wrote about varargs
(we ran into vararg issues during morello porting but it
affects all 64bit targets):

https://lkml.org/lkml/2022/10/31/386
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


  reply	other threads:[~2023-05-23 15:04 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-17 15:03 [PATCH v2 0/5] MDWE without inheritance Florent Revest
2023-05-17 15:03 ` [PATCH v2 1/5] kselftest: vm: Fix tabs/spaces inconsistency in the mdwe test Florent Revest
2023-05-22  8:52   ` David Hildenbrand
2023-05-17 15:03 ` [PATCH v2 2/5] kselftest: vm: Fix mdwe's mmap_FIXED test case Florent Revest
2023-05-22  8:53   ` David Hildenbrand
2023-05-17 15:03 ` [PATCH v2 3/5] mm: Make PR_MDWE_REFUSE_EXEC_GAIN an unsigned long Florent Revest
2023-05-22  8:55   ` David Hildenbrand
     [not found]     ` <884d131bbc28ebfa0b729176e6415269@ispras.ru>
2023-05-22 16:22       ` David Hildenbrand
     [not found]         ` <3c2e210b75bd56909322e8a3e5086d91@ispras.ru>
2023-05-23  9:12           ` David Hildenbrand
2023-05-23 13:07             ` Catalin Marinas
     [not found]               ` <f47d587fe5a6285f88191fbb13f367c7@ispras.ru>
2023-05-23 14:09                 ` Catalin Marinas
2023-05-23 15:01                   ` Szabolcs Nagy [this message]
     [not found]             ` <7c572622c0d8e283fc880fe3f4ffac27@ispras.ru>
2023-05-23 14:10               ` David Hildenbrand
2023-05-26 19:04                 ` Florent Revest
2023-05-26 19:02           ` Florent Revest
2023-05-23 14:11   ` Catalin Marinas
2023-05-17 15:03 ` [PATCH v2 4/5] mm: Add a NO_INHERIT flag to the PR_SET_MDWE prctl Florent Revest
2023-05-22  9:01   ` David Hildenbrand
2023-05-22 16:11     ` Florent Revest
2023-05-23 16:36   ` Catalin Marinas
2023-05-26 19:05     ` Florent Revest
2023-05-17 15:03 ` [PATCH v2 5/5] kselftest: vm: Add tests for no-inherit memory-deny-write-execute Florent Revest

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=ZGzVRO7eCsn7sOe1@arm.com \
    --to=szabolcs.nagy@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=anshuman.khandual@arm.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=david@redhat.com \
    --cc=gthelen@google.com \
    --cc=izbyshev@ispras.ru \
    --cc=joey.gouly@arm.com \
    --cc=keescook@chromium.org \
    --cc=kpsingh@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=peterx@redhat.com \
    --cc=revest@chromium.org \
    --cc=toiwoton@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox