Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1320615 > unrolled thread

Re: [PATCH 1/5] all: s390: move wrapper infrastructure to generic headers

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 1/5] all: s390: move wrapper infrastructure to generic  headers Heiko Carstens <heiko.carstens@de.ibm.com> - 2016-01-28 13:20 +0100
    Re: [PATCH 1/5] all: s390: move wrapper infrastructure to generic  headers Yury Norov <ynorov@caviumnetworks.com> - 2016-01-28 17:40 +0100
      Re: [PATCH 1/5] all: s390: move wrapper infrastructure to generic  headers Yury Norov <ynorov@caviumnetworks.com> - 2016-02-01 12:50 +0100
        Re: [PATCH 1/5] all: s390: move wrapper infrastructure to generic  headers Heiko Carstens <heiko.carstens@de.ibm.com> - 2016-02-02 08:40 +0100
          Re: [PATCH 1/5] all: s390: move wrapper infrastructure to generic  headers Yury Norov <ynorov@caviumnetworks.com> - 2016-02-02 16:50 +0100
            Re: [PATCH 1/5] all: s390: move wrapper infrastructure to generic  headers Heiko Carstens <heiko.carstens@de.ibm.com> - 2016-02-02 17:10 +0100
              Re: [PATCH 1/5] all: s390: move wrapper infrastructure to generic  headers Heiko Carstens <heiko.carstens@de.ibm.com> - 2016-02-02 21:00 +0100
                Re: [PATCH 1/5] all: s390: move wrapper infrastructure to generic  headers Yury Norov <ynorov@caviumnetworks.com> - 2016-02-02 21:50 +0100
                  Re: [PATCH 1/5] all: s390: move wrapper infrastructure to generic  headers Heiko Carstens <heiko.carstens@de.ibm.com> - 2016-02-03 09:10 +0100

#1320615 — Re: [PATCH 1/5] all: s390: move wrapper infrastructure to generic headers

Hello Yury,

On Mon, Jan 25, 2016 at 07:57:23PM +0300, Yury Norov wrote:
> __SC_COMPAT_CAST for s390 is too specific due to 31-bit pointer length, so it's
> moved to arch/s390/include/asm/compat.h. Generic declaration assumes that long,
> unsigned long and pointer types are all 32-bit length.
> 
> linux/syscalls_structs.h header is introduced, because from now (see next patch)
> structure types listed there are needed for both normal and compat mode.
> 
> cond_syscall_wrapped now defined two symbols: sys_foo() and compat_sys_foo(), if
> compat wrappers are enabled.
> 
> Here __SC_WRAP() macro is introduced as well. s390 doesn't need it as it uses
> asm-generated syscall table. But architectures that generate that tables with
> C code (ARM64/ILP32) should redefine it as '#define __SC_WRAP(name) compat_##name'.
> 
> Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>

...

> diff --git a/include/linux/compat.h b/include/linux/compat.h
> index a76c917..1a761ea 100644
> --- a/include/linux/compat.h
> +++ b/include/linux/compat.h
> @@ -718,4 +718,67 @@ asmlinkage long compat_sys_fanotify_mark(int, unsigned int, __u32, __u32,
>  #define is_compat_task() (0)
>  
>  #endif /* CONFIG_COMPAT */
> +
> +#ifdef CONFIG_COMPAT_WRAPPER
> +
> +#ifndef __TYPE_IS_PTR
> +#define __TYPE_IS_PTR(t) (!__builtin_types_compatible_p(typeof(0?(t)0:0ULL), u64))
> +#endif
> +
> +#ifndef __SC_COMPAT_TYPE
> +#define __SC_COMPAT_TYPE(t, a) \
> +	__typeof(__builtin_choose_expr(sizeof(t) > 4, 0L, (t)0)) a
> +#endif
> +
> +#ifndef __SC_COMPAT_CAST
> +#define __SC_COMPAT_CAST(t, a) ({					\
> +	BUILD_BUG_ON((sizeof(t) > 4) && !__TYPE_IS_L(t) &&		\
> +		     !__TYPE_IS_UL(t) && !__TYPE_IS_PTR(t));		\
> +	((t) ((t)(-1) < 0 ? (s64)(s32)(a) : (u64)(u32)(a)));		\
> +})
> +#endif
> +
> +#ifndef SYSCALL_DEFINE_WRAPx
> +/*
> + * The SYSCALL_DEFINE_WRAP macro generates system call wrappers to be used by
> + * compat tasks. These wrappers will only be used for system calls where only
> + * the system call arguments need sign or zero extension or zeroing of upper
> + * bits of pointers.
> + * Note: since the wrapper function will afterwards call a system call which
> + * again performs zero and sign extension for all system call arguments with
> + * a size of less than eight bytes, these compat wrappers only touch those
> + * system call arguments with a size of eight bytes ((unsigned) long and
> + * pointers). Zero and sign extension for e.g. int parameters will be done by
> + * the regular system call wrappers.
> + */
> +#define SYSCALL_DEFINE_WRAPx(x, name, ...)						\
> +asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__));				\
> +asmlinkage long compat_sys##name(__MAP(x,__SC_DECL,__VA_ARGS__))			\
> +		__attribute__((alias(__stringify(compat_SyS##name))));			\
> +asmlinkage long compat_SyS##name(__MAP(x,__SC_COMPAT_TYPE,__VA_ARGS__));		\
> +asmlinkage long compat_SyS##name(__MAP(x,__SC_COMPAT_TYPE,__VA_ARGS__))			\
> +{											\
> +	return sys##name(__MAP(x,__SC_COMPAT_CAST,__VA_ARGS__));			\
> +}											\
> +SYSCALL_DEFINEx(x, name, __VA_ARGS__)
> +#endif
> +
> +#define SYSCALL_DEFINE_WRAP1(name, ...) SYSCALL_DEFINE_WRAPx(1, _##name, __VA_ARGS__)
> +#define SYSCALL_DEFINE_WRAP2(name, ...) SYSCALL_DEFINE_WRAPx(2, _##name, __VA_ARGS__)
> +#define SYSCALL_DEFINE_WRAP3(name, ...) SYSCALL_DEFINE_WRAPx(3, _##name, __VA_ARGS__)
> +#define SYSCALL_DEFINE_WRAP4(name, ...) SYSCALL_DEFINE_WRAPx(4, _##name, __VA_ARGS__)
> +#define SYSCALL_DEFINE_WRAP5(name, ...) SYSCALL_DEFINE_WRAPx(5, _##name, __VA_ARGS__)
> +#define SYSCALL_DEFINE_WRAP6(name, ...) SYSCALL_DEFINE_WRAPx(6, _##name, __VA_ARGS__)
> +
> +#else
> +
> +#define SYSCALL_DEFINE_WRAP1	SYSCALL_DEFINE1
> +#define SYSCALL_DEFINE_WRAP2    SYSCALL_DEFINE2
> +#define SYSCALL_DEFINE_WRAP3    SYSCALL_DEFINE3
> +#define SYSCALL_DEFINE_WRAP4    SYSCALL_DEFINE4
> +#define SYSCALL_DEFINE_WRAP5    SYSCALL_DEFINE5
> +#define SYSCALL_DEFINE_WRAP6    SYSCALL_DEFINE6
> +
> +#endif /* CONFIG_COMPAT_WRAPPER */

How about if you rename SYSCALL_DEFINE_WRAP to SYSCALL_COMPAT_DEFINE which
has the semantics that no dedicated compat system call exists (aka system
call is compat safe).

Then convert all existing SYSCALL_DEFINE'd system calls for which no compat
variant exists to SYSCALL_COMPAT_DEFINE.

This would allow to specify "compat_sys_<syscallname>" in the compat system
call table for _all_ system calls.

No need to look up if a compat variant (or wrapper) exists or
sys_<syscallname> should be used instead. Also no possibility for security
bugs that could creep in because SYSCALL_DEFINE has been used instead of
SYSCALL_DEFINE_WRAP.

Ideally the implementation would only generate an alias if no sign/zero
extension is necessary.

Trivially this would be true for system calls without arguments like e.g.
sys_fork() which would get a compat_sys_fork alias without any further
code.

I'm not sure how difficult it is to implement the same logic for system
calls that have parameters. That is: either generate a
compat_sys_<syscallname> wrapper function, or if the SYSCALL_COMPAT_DEFINE
macro figures out that no zero sign extension is required, only an alias
without any additional code.

I think in the long term something like this is much easier to maintain.

Does that make sense?

[toc] | [next] | [standalone]

#1320850

On Thu, Jan 28, 2016 at 01:16:18PM +0100, Heiko Carstens wrote:
> Hello Yury,
> 
> On Mon, Jan 25, 2016 at 07:57:23PM +0300, Yury Norov wrote:
> > __SC_COMPAT_CAST for s390 is too specific due to 31-bit pointer length, so it's
> > moved to arch/s390/include/asm/compat.h. Generic declaration assumes that long,
> > unsigned long and pointer types are all 32-bit length.
> > 
> > linux/syscalls_structs.h header is introduced, because from now (see next patch)
> > structure types listed there are needed for both normal and compat mode.
> > 
> > cond_syscall_wrapped now defined two symbols: sys_foo() and compat_sys_foo(), if
> > compat wrappers are enabled.
> > 
> > Here __SC_WRAP() macro is introduced as well. s390 doesn't need it as it uses
> > asm-generated syscall table. But architectures that generate that tables with
> > C code (ARM64/ILP32) should redefine it as '#define __SC_WRAP(name) compat_##name'.
> > 
> > Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
> 
> ...
> 

Hi Heiko,

> How about if you rename SYSCALL_DEFINE_WRAP to SYSCALL_COMPAT_DEFINE which
> has the semantics that no dedicated compat system call exists (aka system
> call is compat safe).
> 
> Then convert all existing SYSCALL_DEFINE'd system calls for which no compat
> variant exists to SYSCALL_COMPAT_DEFINE.
> 
> This would allow to specify "compat_sys_<syscallname>" in the compat system
> call table for _all_ system calls.
> 

We can modify SYSCALL_DEFINEx macro to declare weak "compat_sys_<syscallname>"
symbol for each syscall. So if strong compat symbol will be declared
somwere else, it will owerride the weak one. Being under COMPAT_WRAPPER
config, it will not affect someone else except s390 and aarch64/ilp32.
The downside of this approach is that we'll have to move wrapper
machinery to 'include/linux/syscalls.h', thought under wrapper config.

> No need to look up if a compat variant (or wrapper) exists or
> sys_<syscallname> should be used instead. Also no possibility for security
> bugs that could creep in because SYSCALL_DEFINE has been used instead of
> SYSCALL_DEFINE_WRAP.

If we'll choose to stay with current approach, we'll definitely need
to update documentation.

> 
> Ideally the implementation would only generate an alias if no sign/zero
> extension is necessary.
> 
> Trivially this would be true for system calls without arguments like e.g.
> sys_fork() which would get a compat_sys_fork alias without any further
> code.
> 
> I'm not sure how difficult it is to implement the same logic for system
> calls that have parameters. That is: either generate a
> compat_sys_<syscallname> wrapper function, or if the SYSCALL_COMPAT_DEFINE
> macro figures out that no zero sign extension is required, only an alias
> without any additional code.
> 
> I think in the long term something like this is much easier to maintain.
> 
> Does that make sense?

For me, the most important adwantage of this approach is that we don't
need the list of 'magic' system calls anymore. It's even more
important if we'll face a requirement to support ABI that differs from
both natural and ilp32 ABIs. New __SC_COMPAT_CAST will do all the job
for us.

The downsides are that we'll have unneeded wrappers for some syscalls,
if linker will not clear them, and wasting of space if we'll find no
way how to explain compiler to generate simple alias when it's
enough... 

I'll play with it and write you what I'll come to.

Yury.

[toc] | [prev] | [next] | [standalone]

#1323017

On Thu, Jan 28, 2016 at 07:31:09PM +0300, Yury Norov wrote:
> On Thu, Jan 28, 2016 at 01:16:18PM +0100, Heiko Carstens wrote:
> > Hello Yury,
> > 
> > On Mon, Jan 25, 2016 at 07:57:23PM +0300, Yury Norov wrote:
> > > __SC_COMPAT_CAST for s390 is too specific due to 31-bit pointer length, so it's
> > > moved to arch/s390/include/asm/compat.h. Generic declaration assumes that long,
> > > unsigned long and pointer types are all 32-bit length.
> > > 
> > > linux/syscalls_structs.h header is introduced, because from now (see next patch)
> > > structure types listed there are needed for both normal and compat mode.
> > > 
> > > cond_syscall_wrapped now defined two symbols: sys_foo() and compat_sys_foo(), if
> > > compat wrappers are enabled.
> > > 
> > > Here __SC_WRAP() macro is introduced as well. s390 doesn't need it as it uses
> > > asm-generated syscall table. But architectures that generate that tables with
> > > C code (ARM64/ILP32) should redefine it as '#define __SC_WRAP(name) compat_##name'.
> > > 
> > > Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
> > 
> > ...
> > 
> 
> Hi Heiko,
> 
> > How about if you rename SYSCALL_DEFINE_WRAP to SYSCALL_COMPAT_DEFINE which
> > has the semantics that no dedicated compat system call exists (aka system
> > call is compat safe).
> > 
> > Then convert all existing SYSCALL_DEFINE'd system calls for which no compat
> > variant exists to SYSCALL_COMPAT_DEFINE.
> > 
> > This would allow to specify "compat_sys_<syscallname>" in the compat system
> > call table for _all_ system calls.
> > 
> 
> We can modify SYSCALL_DEFINEx macro to declare weak "compat_sys_<syscallname>"
> symbol for each syscall. So if strong compat symbol will be declared
> somwere else, it will owerride the weak one. Being under COMPAT_WRAPPER
> config, it will not affect someone else except s390 and aarch64/ilp32.
> The downside of this approach is that we'll have to move wrapper
> machinery to 'include/linux/syscalls.h', thought under wrapper config.
> 
> > No need to look up if a compat variant (or wrapper) exists or
> > sys_<syscallname> should be used instead. Also no possibility for security
> > bugs that could creep in because SYSCALL_DEFINE has been used instead of
> > SYSCALL_DEFINE_WRAP.
> 
> If we'll choose to stay with current approach, we'll definitely need
> to update documentation.
> 
> > 
> > Ideally the implementation would only generate an alias if no sign/zero
> > extension is necessary.
> > 
> > Trivially this would be true for system calls without arguments like e.g.
> > sys_fork() which would get a compat_sys_fork alias without any further
> > code.
> > 
> > I'm not sure how difficult it is to implement the same logic for system
> > calls that have parameters. That is: either generate a
> > compat_sys_<syscallname> wrapper function, or if the SYSCALL_COMPAT_DEFINE
> > macro figures out that no zero sign extension is required, only an alias
> > without any additional code.
> > 
> > I think in the long term something like this is much easier to maintain.
> > 
> > Does that make sense?
> 
> For me, the most important adwantage of this approach is that we don't
> need the list of 'magic' system calls anymore. It's even more
> important if we'll face a requirement to support ABI that differs from
> both natural and ilp32 ABIs. New __SC_COMPAT_CAST will do all the job
> for us.
> 
> The downsides are that we'll have unneeded wrappers for some syscalls,
> if linker will not clear them, and wasting of space if we'll find no
> way how to explain compiler to generate simple alias when it's
> enough... 
> 
> I'll play with it and write you what I'll come to.
> 
> Yury.

Hi Heiko,

I tried this idea, and I don't like what happened.
 - Wrappers around safe syscalls does exist. We can remove it by
   overcomplicating __SC_COMPAT_CAST, but I don't like it.
 - We still need to declare numerous list of new compat syscalls.
   And it becomes even bigger, as we need to declare all compat
   syscall versions not declared in include/linux/compat.h already.
   (Currently - only for unsafe syscalls.)
 - 'Weak' trick doesn't work for the whole kernel, so we'd figure out
   some new prefix for wrapped syscalls. Or declare all non-compat
   syscalls explicitly with SYSCALL_COMPAT_DEFINE. So the list of
   replacements grow. And for me, it's harder to explain why we are
   wrapping safe syscalls. Or we introduce another bunch of useless
   wrappers (with new prefix), and have to handle it in non-compat code.
 - With all listed above, we move all wrapper logic to non-compat
   'include/linux/syscalls.h' header. Which is not a good idea, if it
   doesn't benefit us much in return.

> > No need to look up if a compat variant (or wrapper) exists or
> > sys_<syscallname> should be used instead. Also no possibility for security
> > bugs that could creep in because SYSCALL_DEFINE has been used instead of
> > SYSCALL_DEFINE_WRAP.

I thought again about it. With current version, it's very easy to
define whether we have wrapper or not - just by macro we use. Once
reviewed, this list is hardly to be changed frequently. If someone is
introducing new syscall, it will attract much attention, so security
risk is minimal.

Maybe I missed some elegant implementation, and if so  I'll be happy
if someone'll point me out. But with what I see, I'd vote for what we
have now. (Plus description in docs, plus renaming new macro.)

Yury.

[toc] | [prev] | [next] | [standalone]

#1323851

On Mon, Feb 01, 2016 at 02:42:51PM +0300, Yury Norov wrote:
> Hi Heiko,
> 
> I tried this idea, and I don't like what happened.
>  - Wrappers around safe syscalls does exist. We can remove it by
>    overcomplicating __SC_COMPAT_CAST, but I don't like it.
>  - We still need to declare numerous list of new compat syscalls.
>    And it becomes even bigger, as we need to declare all compat
>    syscall versions not declared in include/linux/compat.h already.
>    (Currently - only for unsafe syscalls.)
>  - 'Weak' trick doesn't work for the whole kernel, so we'd figure out
>    some new prefix for wrapped syscalls. Or declare all non-compat
>    syscalls explicitly with SYSCALL_COMPAT_DEFINE. So the list of
>    replacements grow. And for me, it's harder to explain why we are
>    wrapping safe syscalls. Or we introduce another bunch of useless
>    wrappers (with new prefix), and have to handle it in non-compat code.
>  - With all listed above, we move all wrapper logic to non-compat
>    'include/linux/syscalls.h' header. Which is not a good idea, if it
>    doesn't benefit us much in return.
> 
> > > No need to look up if a compat variant (or wrapper) exists or
> > > sys_<syscallname> should be used instead. Also no possibility for security
> > > bugs that could creep in because SYSCALL_DEFINE has been used instead of
> > > SYSCALL_DEFINE_WRAP.
> 
> I thought again about it. With current version, it's very easy to
> define whether we have wrapper or not - just by macro we use. Once
> reviewed, this list is hardly to be changed frequently. If someone is
> introducing new syscall, it will attract much attention, so security
> risk is minimal.
> 
> Maybe I missed some elegant implementation, and if so  I'll be happy
> if someone'll point me out. But with what I see, I'd vote for what we
> have now. (Plus description in docs, plus renaming new macro.)

Well, I'd like to have some proof by the compiler or linker that nothing
went wrong. Which seems hard if only selected system call defines will be
converted to the new defines.

How can you tell that nothing has been forgotten?

Also, what happens if the prototype of a system call get's changed shortly
after it was merged. We might miss such changes and have bugs.

Therefore, and to get to a solution, I think we should stick with your
first idea, which only moves the compat_wrapper.c file.

Before doing that I think you should actually revert this patch: my commit
7681df456f97 ("s390/compat: remove superfluous compat wrappers") probably
wasn't a very bright idea :)

This again allows me to use only compat system calls in s390's system call
table (execpt for system calls without parameters, but that can be easily
fixed).

What I still don't like is that you need to add all the protoypes. Why are
the system call tables actually written in C and not in asm?

[toc] | [prev] | [next] | [standalone]

#1324212

On Tue, Feb 02, 2016 at 08:39:13AM +0100, Heiko Carstens wrote:
> On Mon, Feb 01, 2016 at 02:42:51PM +0300, Yury Norov wrote:
> > Hi Heiko,
> > 
> > I tried this idea, and I don't like what happened.
> >  - Wrappers around safe syscalls does exist. We can remove it by
> >    overcomplicating __SC_COMPAT_CAST, but I don't like it.
> >  - We still need to declare numerous list of new compat syscalls.
> >    And it becomes even bigger, as we need to declare all compat
> >    syscall versions not declared in include/linux/compat.h already.
> >    (Currently - only for unsafe syscalls.)
> >  - 'Weak' trick doesn't work for the whole kernel, so we'd figure out
> >    some new prefix for wrapped syscalls. Or declare all non-compat
> >    syscalls explicitly with SYSCALL_COMPAT_DEFINE. So the list of
> >    replacements grow. And for me, it's harder to explain why we are
> >    wrapping safe syscalls. Or we introduce another bunch of useless
> >    wrappers (with new prefix), and have to handle it in non-compat code.
> >  - With all listed above, we move all wrapper logic to non-compat
> >    'include/linux/syscalls.h' header. Which is not a good idea, if it
> >    doesn't benefit us much in return.
> > 
> > > > No need to look up if a compat variant (or wrapper) exists or
> > > > sys_<syscallname> should be used instead. Also no possibility for security
> > > > bugs that could creep in because SYSCALL_DEFINE has been used instead of
> > > > SYSCALL_DEFINE_WRAP.
> > 
> > I thought again about it. With current version, it's very easy to
> > define whether we have wrapper or not - just by macro we use. Once
> > reviewed, this list is hardly to be changed frequently. If someone is
> > introducing new syscall, it will attract much attention, so security
> > risk is minimal.
> > 
> > Maybe I missed some elegant implementation, and if so  I'll be happy
> > if someone'll point me out. But with what I see, I'd vote for what we
> > have now. (Plus description in docs, plus renaming new macro.)
> 
> Well, I'd like to have some proof by the compiler or linker that nothing
> went wrong. Which seems hard if only selected system call defines will be
> converted to the new defines.
> 
> How can you tell that nothing has been forgotten?
> 
> Also, what happens if the prototype of a system call get's changed shortly
> after it was merged. We might miss such changes and have bugs.
> 

As for now, there's no such proof, and everything is OK. Syscall ABI
is extremely conservative, and Greg KH, and other people spent a lot
of efforts to keep it that way. This is the only reason for me to not
worry much about it. Modification of syscall ABI is virtually
impossible now, because it breaks binary compatibility. Even addition
of new syscall is very difficult procedure.
(Documentation/adding-syscalls.txt begins with section "System Call
Alternatives".)

We can invent some protection, but it will cost us in complexity and/or
runtime delays. Because syscall ABI is so stable, I think it's OK to
review wrappers carefully once, and they will be fine for long time.

> Therefore, and to get to a solution, I think we should stick with your
> first idea, which only moves the compat_wrapper.c file.
> 
> Before doing that I think you should actually revert this patch: my commit
> 7681df456f97 ("s390/compat: remove superfluous compat wrappers") probably
> wasn't a very bright idea :)
> 

This patch is OK for me. pid_t, uid_t, gid_t, unsigned and signed int
types are all 32-bit both on LP64 and ILP32. Normally, compiler should
care about top halves... Did I miss something?

> This again allows me to use only compat system calls in s390's system call
> table (execpt for system calls without parameters, but that can be easily
> fixed).
> 
> What I still don't like is that you need to add all the protoypes. Why are
> the system call tables actually written in C and not in asm?

Because generic unistd code is multi-platform by intention.

I don't know much about s390 specifics. Maybe because of that I do not
understand completely your worries. I'm OK with both 1st and 2nd
version, but I'd choose 2nd one because it allows inlines, and we
don't need the compat_wrapper.c. 

[toc] | [prev] | [next] | [standalone]

#1324231

On Tue, Feb 02, 2016 at 06:43:31PM +0300, Yury Norov wrote:
> > Well, I'd like to have some proof by the compiler or linker that nothing
> > went wrong. Which seems hard if only selected system call defines will be
> > converted to the new defines.
> > 
> > How can you tell that nothing has been forgotten?
> > 
> > Also, what happens if the prototype of a system call get's changed shortly
> > after it was merged. We might miss such changes and have bugs.
> > 
> 
> As for now, there's no such proof, and everything is OK. Syscall ABI
> is extremely conservative, and Greg KH, and other people spent a lot
> of efforts to keep it that way. This is the only reason for me to not
> worry much about it. Modification of syscall ABI is virtually
> impossible now, because it breaks binary compatibility. Even addition
> of new syscall is very difficult procedure.
> (Documentation/adding-syscalls.txt begins with section "System Call
> Alternatives".)

Well... during the years a lot of system calls have been added. And we've
also seen last-minute changes or reverts. So I don't share your optimistic
view here :)

See e.g. 485d52768685 ("sys_personality: change sys_personality() to accept
"unsigned int" instead of u_long") would have been a candidate which could
silently break architectures which need compat wrappers.

> We can invent some protection, but it will cost us in complexity and/or
> runtime delays. Because syscall ABI is so stable, I think it's OK to
> review wrappers carefully once, and they will be fine for long time.

Here I don't agree with you. These interfaces are so important that I'd
like to have a waterproof method that these don't break.  If this involves
a couple of superfluous instructions then that's what I'm willing to pay
for it.

> > Before doing that I think you should actually revert this patch: my commit
> > 7681df456f97 ("s390/compat: remove superfluous compat wrappers") probably
> > wasn't a very bright idea :)
> This patch is OK for me. pid_t, uid_t, gid_t, unsigned and signed int
> types are all 32-bit both on LP64 and ILP32. Normally, compiler should
> care about top halves... Did I miss something?

The patch was correct when writing it, but e.g. a patch like named above
would introduce a possible bug which would go in unnoticed.
The only thing we save is a _single_ unconditional branch here. I'd say
that's well worth it if you get a (hopefully) always bug free sign and zero
extension infrastructure in return.

> I don't know much about s390 specifics. Maybe because of that I do not
> understand completely your worries. I'm OK with both 1st and 2nd
> version, but I'd choose 2nd one because it allows inlines, and we
> don't need the compat_wrapper.c.

It would be only nicer if we can guarentee correctness all the time. That
being said I'm about to revert my own commit :)

So if you want to go without compat_wrapper.c then we should have a
solution which will do the right thing all the time without that a system
call author has to know about the sign and zero extension issue some
architectures face. It _will_ go wrong.

[toc] | [prev] | [next] | [standalone]

#1324577

Hi Yury,

On Tue, Feb 02, 2016 at 05:08:26PM +0100, Heiko Carstens wrote:
> See e.g. 485d52768685 ("sys_personality: change sys_personality() to accept
> "unsigned int" instead of u_long") would have been a candidate which could
> silently break architectures which need compat wrappers.

Ok, this example is of course wrong. But now I can claim that also somebody
who should know better makes these mistakes.. :)

> > I don't know much about s390 specifics. Maybe because of that I do not
> > understand completely your worries. I'm OK with both 1st and 2nd
> > version, but I'd choose 2nd one because it allows inlines, and we
> > don't need the compat_wrapper.c.
> 
> It would be only nicer if we can guarentee correctness all the time. That
> being said I'm about to revert my own commit :)
> 
> So if you want to go without compat_wrapper.c then we should have a
> solution which will do the right thing all the time without that a system
> call author has to know about the sign and zero extension issue some
> architectures face. It _will_ go wrong.

So I think I can summarize my point to: if you can enforce correctness, why
shouldn't you do it if the performance impact is only a single instruction.

However I'll try to write an addon patch to your patch series. Maybe we can
still get rid of compat_wrapper.c in a way which makes both of us happy.
Also.. the idea with the alias names for compat wrappers does seem to have
the disadvantage that it will pollute /proc/kallsyms for example.

Anyway, I'm not sure if I will be able to come up with something this week
though.

[toc] | [prev] | [next] | [standalone]

#1324616

On Tue, Feb 02, 2016 at 08:54:34PM +0100, Heiko Carstens wrote:
> Hi Yury,
> 
> On Tue, Feb 02, 2016 at 05:08:26PM +0100, Heiko Carstens wrote:
> > See e.g. 485d52768685 ("sys_personality: change sys_personality() to accept
> > "unsigned int" instead of u_long") would have been a candidate which could
> > silently break architectures which need compat wrappers.
> 
> Ok, this example is of course wrong. But now I can claim that also somebody
> who should know better makes these mistakes.. :)
> 

Yep, this is a bad example. :) Moreover, this patch is coming from year 2010,
and it shows how stable the syscall ABI is.

> > > I don't know much about s390 specifics. Maybe because of that I do not
> > > understand completely your worries. I'm OK with both 1st and 2nd
> > > version, but I'd choose 2nd one because it allows inlines, and we
> > > don't need the compat_wrapper.c.
> > 
> > It would be only nicer if we can guarentee correctness all the time. That
> > being said I'm about to revert my own commit :)
> > 
> > So if you want to go without compat_wrapper.c then we should have a
> > solution which will do the right thing all the time without that a system
> > call author has to know about the sign and zero extension issue some
> > architectures face. It _will_ go wrong.
> 
> So I think I can summarize my point to: if you can enforce correctness, why
> shouldn't you do it if the performance impact is only a single instruction.

For aarch64 it's 5 instructions. But what's more important (if ever),
another wrapper takes another i-cache line...
        <compat_SyS_ftruncate>:
        stp     x29, x30, [sp,#-16]!
        mov     x29, sp
        bl      d40 <do_sys_ftruncate.constprop.3>
        ldp     x29, x30, [sp],#16
        ret

> 
> However I'll try to write an addon patch to your patch series. Maybe we can
> still get rid of compat_wrapper.c in a way which makes both of us happy.
> Also.. the idea with the alias names for compat wrappers does seem to have
> the disadvantage that it will pollute /proc/kallsyms for example.
> 
> Anyway, I'm not sure if I will be able to come up with something this week
> though.

Great, I'm looking forward...

My point is. Syscall ABI is so stable and so important that too much
people are involved in development and testing of it. So automatic
checks are almost useless, as all bugs will be found during
development and review. I think, community is able to pay enough
attention to review a couple of such patches per decade.
But I'm OK with some automatic checker, if it will be :
 - not too complicated, as complex code makes bugs by itself;
 - not too expensive;
 - not too ugly (my one is definitely ugly).

[toc] | [prev] | [next] | [standalone]

#1325013

On Tue, Feb 02, 2016 at 11:41:56PM +0300, Yury Norov wrote:
> On Tue, Feb 02, 2016 at 08:54:34PM +0100, Heiko Carstens wrote:
> > So I think I can summarize my point to: if you can enforce correctness, why
> > shouldn't you do it if the performance impact is only a single instruction.
> 
> For aarch64 it's 5 instructions. But what's more important (if ever),
> another wrapper takes another i-cache line...
>         <compat_SyS_ftruncate>:
>         stp     x29, x30, [sp,#-16]!
>         mov     x29, sp
>         bl      d40 <do_sys_ftruncate.constprop.3>
>         ldp     x29, x30, [sp],#16
>         ret

Why does gcc allocate a stackframe here? Don't you have tail call
optimization?

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web