linux-um.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Berg <benjamin@sipsolutions.net>
To: Johannes Berg <johannes@sipsolutions.net>,
	Yonting Lin <linyongting@gmail.com>,
	development@efficientek.com
Cc: linux-um@lists.infradead.org
Subject: Re: [PATCH] um: fix execve stub execution on old host OSs
Date: Mon, 09 Jun 2025 19:23:46 +0200	[thread overview]
Message-ID: <e8a409845399538585e547b361a4210c21b5215f.camel@sipsolutions.net> (raw)
In-Reply-To: <370a1b96fb029ef2afe7fcaf4b9daad40804a730.camel@sipsolutions.net> (sfid-20250609_191550_661037_A6821748)

On Mon, 2025-06-09 at 19:15 +0200, Johannes Berg wrote:
> On Sun, 2025-06-08 at 20:38 +0200, Benjamin Berg wrote:
> > > 
> > > But my host kernel is 5.4 and fails to compile these pieces of
> > > codes because
> > > there is no this syscall in my older kernel.
> > > 
> > > I was wondering if you are working on this issue. If not, I will
> > > try to 
> > > make a draft solution to review.
> > 
> > I was not yet aware of that problem. Most likely only the one in
> > start_up.c is a problem for you. All the other ones probably pick
> > up
> > the correct definition from the Linux tree already.
> > 
> > One can probably solve it by moving the code into another file. Or
> > maybe by adding an entry for __NR_close_range into common-offests.h
> > and
> > using that.
> 
> Seems though we might need to add checking for close_range to the
> seccomp init though, it's actually (much) newer than seccomp. Or just
> not rely on it?

That check is what is failing now :-)

We already introduced close_range use earlier, but in ptrace mode it is
just about hygiene rather than actually being safety relevant. So we
just accept the syscall failure there.

Benjamin


      reply	other threads:[~2025-06-09 18:43 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-10 16:13 [PATCH] um: fix execve stub execution on old host OSs Benjamin Berg
2025-01-12 20:07 ` Glenn Washburn
2025-01-13  7:08   ` Benjamin Berg
2025-06-07  4:22   ` Yonting Lin
2025-06-08 18:38     ` Benjamin Berg
2025-06-09  9:17       ` ivan lin
2025-06-09 17:15       ` Johannes Berg
2025-06-09 17:23         ` Benjamin Berg [this message]

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=e8a409845399538585e547b361a4210c21b5215f.camel@sipsolutions.net \
    --to=benjamin@sipsolutions.net \
    --cc=development@efficientek.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-um@lists.infradead.org \
    --cc=linyongting@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;
as well as URLs for NNTP newsgroup(s).