From: "Pali Rohár" <pali@kernel.org>
To: Kees Cook <kees@kernel.org>
Cc: Eric Biederman <ebiederm@xmission.com>,
Kees Cook <keescook@chromium.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: binfmt_misc & different PE binaries
Date: Mon, 7 Aug 2023 19:08:52 +0200 [thread overview]
Message-ID: <20230807170852.yefmkcqwum6gdao6@pali> (raw)
In-Reply-To: <C636CC6D-9504-4B81-8B47-2734C70F20C2@kernel.org>
On Monday 07 August 2023 07:45:08 Kees Cook wrote:
> On August 6, 2023 9:23:46 AM PDT, "Pali Rohár" <pali@kernel.org> wrote:
> >Hello, I would like to remind this email about binfmt_misc for PE.
> >
> >On Thursday 06 July 2023 13:55:50 Pali Rohár wrote:
> >> Hello,
> >>
> >> I would like to ask how to properly register binfmt_misc for different
> >> PE binaries, so kernel could execute the correct loader for them.
> >>
> >> I mean, how to register support for Win32 (console/gui) PE binaries and
> >> also for CLR PE binaries (dotnet). Win32 needs to be executed under wine
> >> and CLR ideally under dotnet core (or mono).
> >>
> >> I have read kernel documentation files admin-guide/binfmt-misc.rst
> >> and admin-guide/mono.rst. But seems that they are in conflicts as both
> >> wants to registers its own handler for the same magic:
> >>
> >> echo ':DOSWin:M::MZ::/usr/local/bin/wine:' > register
> >>
> >> echo ':CLR:M::MZ::/usr/bin/mono:' > /proc/sys/fs/binfmt_misc/register
> >>
> >> Not mentioning the fact that they register DOS MZ handler, which matches
> >> not only all PE binaries (including EFI, libraries, other processors),
> >> but also all kind of other NE/LE/LX binaries and different DOS extenders.
> >>
> >> From documentation it looks like that even registering PE binaries is
> >> impossible by binfmt_misc as PE is detected by checking that indirect
> >> reference from 0x3C is PE\0\0. And distinguish between Win32 and CLR
> >> needs to parse PE COM descriptor directory.
> >>
> >> Or it is possible to write binfmt_misc pattern match based on indirect
> >> offset?
>
> Normally a single userspace program will be registered and it can do whatever it needs to do to further distinguish the binary and hand it off to the appropriate loader.
>
>
>
> --
> Kees Cook
Ok, so you are saying that there should be one userspace program which
distinguish between DOS, CLR and Win32 and then exec the correct
"runtime" loader? Is there such one? Also it would be nice to mention it
in the documentation.
next prev parent reply other threads:[~2023-08-07 17:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-06 11:55 Pali Rohár
2023-08-06 16:23 ` Pali Rohár
2023-08-07 14:45 ` Kees Cook
2023-08-07 17:08 ` Pali Rohár [this message]
2023-08-10 20:24 ` Kees Cook
2023-08-11 19:05 ` Pali Rohár
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=20230807170852.yefmkcqwum6gdao6@pali \
--to=pali@kernel.org \
--cc=ebiederm@xmission.com \
--cc=kees@kernel.org \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/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