All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Borislav Petkov <bp@alien8.de>
Cc: "Jan Kara" <jack@suse.cz>, "Paweł Jasiak" <pawel@jasiak.xyz>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	x86@kernel.org, "Thomas Gleixner" <tglx@linutronix.de>,
	"Brian Gerst" <brgerst@gmail.com>,
	"Andy Lutomirski" <luto@kernel.org>
Subject: Re: PROBLEM: fanotify_mark EFAULT on x86
Date: Thu, 26 Nov 2020 11:48:27 +0100	[thread overview]
Message-ID: <20201126104827.GA422@quack2.suse.cz> (raw)
In-Reply-To: <20201124102814.GE4009@zn.tnic>

On Tue 24-11-20 11:28:14, Borislav Petkov wrote:
> On Tue, Nov 24, 2020 at 11:20:33AM +0100, Jan Kara wrote:
> > On Tue 24-11-20 09:45:07, Borislav Petkov wrote:
> > > On Mon, Nov 23, 2020 at 11:46:51PM +0100, Paweł Jasiak wrote:
> > > > On 23/11/20, Jan Kara wrote:
> > > > > OK, with a help of Boris Petkov I think I have a fix that looks correct
> > > > > (attach). Can you please try whether it works for you? Thanks!
> > > > 
> > > > Unfortunately I am getting a linker error.
> > > > 
> > > > ld: arch/x86/entry/syscall_32.o:(.rodata+0x54c): undefined reference to `__ia32_sys_ia32_fanotify_mark'
> > > 
> > > Because CONFIG_COMPAT is not set in your .config.
> > > 
> > > Jan, look at 121b32a58a3a and especially this hunk
> > > 
> > > diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
> > > index 9b294c13809a..b8f89f78b8cd 100644
> > > --- a/arch/x86/kernel/Makefile
> > > +++ b/arch/x86/kernel/Makefile
> > > @@ -53,6 +53,8 @@ obj-y                 += setup.o x86_init.o i8259.o irqinit.o
> > >  obj-$(CONFIG_JUMP_LABEL)       += jump_label.o
> > >  obj-$(CONFIG_IRQ_WORK)  += irq_work.o
> > >  obj-y                  += probe_roms.o
> > > +obj-$(CONFIG_X86_32)   += sys_ia32.o
> > > +obj-$(CONFIG_IA32_EMULATION)   += sys_ia32.o
> > > 
> > > how it enables the ia32 syscalls depending on those config items. Now,
> > > you have
> > > 
> > >  #ifdef CONFIG_COMPAT
> > > -COMPAT_SYSCALL_DEFINE6(fanotify_mark,
> > > +SYSCALL_DEFINE6(ia32_fanotify_mark,
> > > 
> > > which is under CONFIG_COMPAT which is not set in Paweł's config.
> > > 
> > > config COMPAT
> > >         def_bool y
> > >         depends on IA32_EMULATION || X86_X32
> > > 
> > > but it depends on those two config items.
> > > 
> > > However, it looks to me like ia32_fanotify_mark's definition should be
> > > simply under CONFIG_X86_32 because:
> > > 
> > > IA32_EMULATION is 32-bit emulation on 64-bit kernels
> > > X86_X32 is for the x32 ABI
> > 
> > Thanks for checking! I didn't realize I needed to change the ifdefs as well
> > (I missed that bit in 121b32a58a3a). So do I understand correctly that
> > whenever the kernel is 64-bit, 64-bit syscall args (e.g. defined as u64) are
> > passed just fine regardless of whether the userspace is 32-bit or not?
> > 
> > Also how about other 32-bit archs? Because I now realized that
> > CONFIG_COMPAT as well as the COMPAT_SYSCALL_DEFINE6() is also utilized by
> > other 32-bit archs (I can see a reference to compat_sys_fanotify_mark e.g.
> > in sparc, powerpc, and other args). So I probably need to actually keep
> > that for other archs but do the modification only for x86, don't I?
> 
> Hmm, you raise a good point and looking at that commit again, the
> intention is to supply those ia32 wrappers as both 32-bit native *and*
> 32-bit emulation ones.
> 
> So I think this
> 
> > -#ifdef CONFIG_COMPAT
> > +#if defined(CONFIG_COMPAT) || defined(CONFIG_X86_32)
> > +#ifdef CONFIG_X86_32
> > +SYSCALL_DEFINE6(ia32_fanotify_mark,
> > +#elif CONFIG_COMPAT
> >  COMPAT_SYSCALL_DEFINE6(fanotify_mark,
> > +#endif
> 
> should be
> 
> if defined(CONFIG_X86_32) || defined(CONFIG_IA32_EMULATION)
> SYSCALL_DEFINE6(ia32_fanotify_mark,
> #elif CONFIG_COMPAT
> COMPAT_SYSCALL_DEFINE6(fanotify_mark,
> #endif
> 
> or so.
> 
> Meaning that 32-bit native or 32-bit emulation supplies
> ia32_fanotify_mark() as a syscall wrapper and other arches doing
> CONFIG_COMPAT, still do the COMPAT_SYSCALL_DEFINE6() thing.

Yeah, looking again at what those config options mean I agree. Patch
updated.

> But I'd prefer if someone more knowledgeable than me in that whole
> syscall macros muck to have a look...

I'd prefer that as well but if nobody pops up, I'll just push this to my
tree next week and will see what breaks :)

								Honza

-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

  reply	other threads:[~2020-11-26 10:48 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-01 21:27 PROBLEM: fanotify_mark EFAULT on x86 Paweł Jasiak
2020-11-01 21:38 ` Matthew Wilcox
2020-11-01 22:27   ` Paweł Jasiak
2020-11-02 12:26 ` Jan Kara
2020-11-02 17:16   ` Paweł Jasiak
2020-11-03 21:17   ` Paweł Jasiak
2020-11-04 10:14     ` Jan Kara
2020-11-23 16:46     ` Jan Kara
2020-11-23 22:46       ` Paweł Jasiak
2020-11-24  8:45         ` Borislav Petkov
2020-11-24 10:20           ` Jan Kara
2020-11-24 10:28             ` Borislav Petkov
2020-11-26 10:48               ` Jan Kara [this message]
2020-11-26 10:52                 ` Borislav Petkov
2020-11-25 19:31             ` Naresh Kamboju
2020-11-26 10:48               ` Jan Kara
2020-11-23 23:07       ` [PATCH] fanotify: Fix fanotify_mark() on 32-bit archs kernel test robot
2020-11-23 23:07         ` kernel test robot

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=20201126104827.GA422@quack2.suse.cz \
    --to=jack@suse.cz \
    --cc=bp@alien8.de \
    --cc=brgerst@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=pawel@jasiak.xyz \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.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 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.