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

[Yury Norov]

On Wed, Feb 17, 2016 at 09:22:10AM +0100, Heiko Carstens wrote:
> On Tue, Feb 02, 2016 at 11:41:56PM +0300, Yury Norov wrote:
> > > 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...
> 
> Hi Yuri,
> 
> after playing around with this a bit I couldn't come up with a solution
> that I'm happy with, unfortunately.
> 
> So in order to make some progress here I'd vote that we simply move the
> existing compat_wrapper.c from arch/s390 to common code like you did in
> your first approach and leave the existing SYSCALL macros alone.
> 
> That will have hardly any effect to anybody else and your problem is
> solved while s390 still works.
> 
> Does that make sense?
> 

OK. This week I'll split v1 as I did with v2, and send it here. So
we'll have two versions, and so will start true elections. :)

> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Yury Norov]

On Wed, Feb 17, 2016 at 09:22:10AM +0100, Heiko Carstens wrote:
> On Tue, Feb 02, 2016 at 11:41:56PM +0300, Yury Norov wrote:
> > > 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...
> 
> Hi Yuri,
> 
> after playing around with this a bit I couldn't come up with a solution
> that I'm happy with, unfortunately.
> 
> So in order to make some progress here I'd vote that we simply move the
> existing compat_wrapper.c from arch/s390 to common code like you did in
> your first approach and leave the existing SYSCALL macros alone.
> 
> That will have hardly any effect to anybody else and your problem is
> solved while s390 still works.
> 
> Does that make sense?
> 

OK. This week I'll split v1 as I did with v2, and send it here. So
we'll have two versions, and so will start true elections. :)

> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Heiko Carstens]

On Tue, Feb 02, 2016 at 11:41:56PM +0300, Yury Norov wrote:
> > 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...

Hi Yuri,

after playing around with this a bit I couldn't come up with a solution
that I'm happy with, unfortunately.

So in order to make some progress here I'd vote that we simply move the
existing compat_wrapper.c from arch/s390 to common code like you did in
your first approach and leave the existing SYSCALL macros alone.

That will have hardly any effect to anybody else and your problem is
solved while s390 still works.

Does that make sense?

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

[Heiko Carstens]

On Tue, Feb 02, 2016 at 11:41:56PM +0300, Yury Norov wrote:
> > 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...

Hi Yuri,

after playing around with this a bit I couldn't come up with a solution
that I'm happy with, unfortunately.

So in order to make some progress here I'd vote that we simply move the
existing compat_wrapper.c from arch/s390 to common code like you did in
your first approach and leave the existing SYSCALL macros alone.

That will have hardly any effect to anybody else and your problem is
solved while s390 still works.

Does that make sense?

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

[Heiko Carstens]

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...
> :
> stp x29, x30, [sp,#-16]!
> mov x29, sp
> bl  d40 
> ldp x29, x30, [sp],#16
> ret

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

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

[Heiko Carstens]

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...
> :
> stp x29, x30, [sp,#-16]!
> mov x29, sp
> bl  d40 
> ldp x29, x30, [sp],#16
> ret

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

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

[Yury Norov]

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...
:
stp x29, x30, [sp,#-16]!
mov x29, sp
bl  d40 
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).

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

[Heiko Carstens]

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.

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

[Heiko Carstens]

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.

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

[Yury Norov]

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_ 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. 

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

[Yury Norov]

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...
:
stp x29, x30, [sp,#-16]!
mov x29, sp
bl  d40 
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).

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

[Heiko Carstens]

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.

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

[Yury Norov]

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_ 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. 

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

[Heiko Carstens]

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.

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

[Heiko Carstens]

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_ 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?

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

[Yury Norov]

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 
> > 
> > ...
> > 
> 
> 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_" in the compat system
> > call table for _all_ system calls.
> > 
> 
> We can modify SYSCALL_DEFINEx macro to declare weak "compat_sys_"
> 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_ 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_ 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_ 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 

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

[Yury Norov]

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 
> > 
> > ...
> > 
> 
> 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_" in the compat system
> > call table for _all_ system calls.
> > 
> 
> We can modify SYSCALL_DEFINEx macro to declare weak "compat_sys_"
> 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_ 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_ 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_ 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 

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

[Heiko Carstens]

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_ 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?

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

[Yury Norov]

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 
> 
> ...
> 

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_" in the compat system
> call table for _all_ system calls.
> 

We can modify SYSCALL_DEFINEx macro to declare weak "compat_sys_"
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_ 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_ 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.

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

[Heiko Carstens]

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 

...

> 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_WRAP2SYSCALL_DEFINE2
> +#define SYSCALL_DEFINE_WRAP3SYSCALL_DEFINE3
> +#define SYSCALL_DEFINE_WRAP4SYSCALL_DEFINE4
> +#define SYSCALL_DEFINE_WRAP5SYSCALL_DEFINE5
> +#define SYSCALL_DEFINE_WRAP6SYSCALL_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_" in the compat system
call table for _all_ system calls.

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

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

[Yury Norov]

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 
> 
> ...
> 

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_" in the compat system
> call table for _all_ system calls.
> 

We can modify SYSCALL_DEFINEx macro to declare weak "compat_sys_"
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_ 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_ 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.

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

[Heiko Carstens]

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 

...

> 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_WRAP2SYSCALL_DEFINE2
> +#define SYSCALL_DEFINE_WRAP3SYSCALL_DEFINE3
> +#define SYSCALL_DEFINE_WRAP4SYSCALL_DEFINE4
> +#define SYSCALL_DEFINE_WRAP5SYSCALL_DEFINE5
> +#define SYSCALL_DEFINE_WRAP6SYSCALL_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_" in the compat system
call table for _all_ system calls.

No need to look up if a compat variant (or wrapper) exists or
sys_ should be used instead. Also no possibility for security
bugs that could creep in because 

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

[kbuild test robot]

Hi Yury,

[auto build test ERROR on v4.4-rc8]
[also build test ERROR on next-20160125]
[cannot apply to s390/features v4.5-rc1]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Yury-Norov/all-s390-move-wrapper-infrastructure-to-generic-headers/20160126-010134
config: s390-allyesconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=s390 

Note: the 
linux-review/Yury-Norov/all-s390-move-wrapper-infrastructure-to-generic-headers/20160126-010134
 HEAD ef38065534a44f2efabd66ed0860b822cf98e49e builds fine.
  It only hurts bisectibility.

All error/warnings (new ones prefixed by >>):

   fs/notify/fanotify/fanotify_user.c: In function 'compat_SyS_fanotify_mark':
   fs/notify/fanotify/fanotify_user.c:913:1: error: implicit declaration of 
function '__TYPE_IS_PTR' [-Werror=implicit-function-declaration]
COMPAT_SYSCALL_DEFINE6(fanotify_mark,
^
   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/uapi/linux/fanotify.h:4,
from include/linux/fanotify.h:4,
from fs/notify/fanotify/fanotify_user.c:1:
   fs/notify/fanotify/fanotify_user.c:914:5: error: expected expression before 
'int'
int, fanotify_fd, unsigned int, flags,
^
   include/linux/compiler.h:464:19: note: in definition of macro 
'__compiletime_assert'
  bool __cond = !(condition);\
  ^
   include/linux/compiler.h:484:2: note: in expansion of macro 
'_compiletime_assert'
 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
 ^
   include/linux/bug.h:50:37: note: in expansion of macro 'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^
   include/linux/bug.h:74:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
 BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
 ^
>> arch/s390/include/asm/compat.h:11:2: note: in expansion of macro 
>> 'BUILD_BUG_ON'
 BUILD_BUG_ON(sizeof(t) > 4 && !__TYPE_IS_PTR(t)); \
 ^
>> include/linux/syscalls.h:43:27: note: in expansion of macro '__SC_DELOUSE'
#define __MAP6(m,t,a,...) m(t,a), __MAP5(m,__VA_ARGS__)
  ^
>> include/linux/syscalls.h:44:22: note: in expansion of macro '__MAP6'
#define __MAP(n,...) __MAP##n(__VA_ARGS__)
 ^
>> include/linux/compat.h:54:23: note: in expansion of macro '__MAP'
  return C_SYSC##name(__MAP(x,__SC_DELOUSE,__VA_ARGS__)); \
  ^
>> include/linux/compat.h:45:2: note: in expansion of macro 
>> 'COMPAT_SYSCALL_DEFINEx'
 COMPAT_SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
 ^
   fs/notify/fanotify/fanotify_user.c:913:1: note: in expansion of macro 
'COMPAT_SYSCALL_DEFINE6'
COMPAT_SYSCALL_DEFINE6(fanotify_mark,
^
   In file included from include/linux/compat.h:19:0,
from fs/notify/fanotify/fanotify_user.c:16:
   fs/notify/fanotify/fanotify_user.c:914:5: error: expected expression before 
'int'
int, fanotify_fd, unsigned int, flags,
^
   arch/s390/include/asm/compat.h:12:20: note: in definition of macro 
'__SC_DELOUSE'
 (t)(__TYPE_IS_PTR(t) ? ((v) & 0x7fff) : (v)); \
   ^
>> include/linux/syscalls.h:44:22: note: in expansion of macro '__MAP6'
#define __MAP(n,...) __MAP##n(__VA_ARGS__)
 ^
>> include/linux/compat.h:54:23: note: in expansion of macro '__MAP'
  return C_SYSC##name(__MAP(x,__SC_DELOUSE,__VA_ARGS__)); \
  ^
>> include/linux/compat.h:45:2: note: in expansion of macro 
>> 'COMPAT_SYSCALL_DEFINEx'
 COMPAT_SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
 ^
   fs/notify/fanotify/fanotify_user.c:913:1: note: in expansion of macro 
'COMPAT_SYSCALL_DEFINE6'
COMPAT_SYSCALL_DEFINE6(fanotify_mark,
^
   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/uapi/linux/fanotify.h:4,
from include/linux/fanotify.h:4,
from fs/notify/fanotify/fanotify_user.c:1:
   fs/notify/fanotify/fanotify_user.c:914:23: error: expected expression before 
'unsigned'
int, fanotify_fd, unsigned int, flags,
 

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

[kbuild test robot]

Hi Yury,

[auto build test ERROR on v4.4-rc8]
[also build test ERROR on next-20160125]
[cannot apply to s390/features v4.5-rc1]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Yury-Norov/all-s390-move-wrapper-infrastructure-to-generic-headers/20160126-010134
config: s390-allyesconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=s390 

Note: the 
linux-review/Yury-Norov/all-s390-move-wrapper-infrastructure-to-generic-headers/20160126-010134
 HEAD ef38065534a44f2efabd66ed0860b822cf98e49e builds fine.
  It only hurts bisectibility.

All error/warnings (new ones prefixed by >>):

   fs/notify/fanotify/fanotify_user.c: In function 'compat_SyS_fanotify_mark':
   fs/notify/fanotify/fanotify_user.c:913:1: error: implicit declaration of 
function '__TYPE_IS_PTR' [-Werror=implicit-function-declaration]
COMPAT_SYSCALL_DEFINE6(fanotify_mark,
^
   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/uapi/linux/fanotify.h:4,
from include/linux/fanotify.h:4,
from fs/notify/fanotify/fanotify_user.c:1:
   fs/notify/fanotify/fanotify_user.c:914:5: error: expected expression before 
'int'
int, fanotify_fd, unsigned int, flags,
^
   include/linux/compiler.h:464:19: note: in definition of macro 
'__compiletime_assert'
  bool __cond = !(condition);\
  ^
   include/linux/compiler.h:484:2: note: in expansion of macro 
'_compiletime_assert'
 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
 ^
   include/linux/bug.h:50:37: note: in expansion of macro 'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^
   include/linux/bug.h:74:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
 BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
 ^
>> arch/s390/include/asm/compat.h:11:2: note: in expansion of macro 
>> 'BUILD_BUG_ON'
 BUILD_BUG_ON(sizeof(t) > 4 && !__TYPE_IS_PTR(t)); \
 ^
>> include/linux/syscalls.h:43:27: note: in expansion of macro '__SC_DELOUSE'
#define __MAP6(m,t,a,...) m(t,a), __MAP5(m,__VA_ARGS__)
  ^
>> include/linux/syscalls.h:44:22: note: in expansion of macro '__MAP6'
#define __MAP(n,...) __MAP##n(__VA_ARGS__)
 ^
>> include/linux/compat.h:54:23: note: in expansion of macro '__MAP'
  return C_SYSC##name(__MAP(x,__SC_DELOUSE,__VA_ARGS__)); \
  ^
>> include/linux/compat.h:45:2: note: in expansion of macro 
>> 'COMPAT_SYSCALL_DEFINEx'
 COMPAT_SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
 ^
   fs/notify/fanotify/fanotify_user.c:913:1: note: in expansion of macro 
'COMPAT_SYSCALL_DEFINE6'
COMPAT_SYSCALL_DEFINE6(fanotify_mark,
^
   In file included from include/linux/compat.h:19:0,
from fs/notify/fanotify/fanotify_user.c:16:
   fs/notify/fanotify/fanotify_user.c:914:5: error: expected expression before 
'int'
int, fanotify_fd, unsigned int, flags,
^
   arch/s390/include/asm/compat.h:12:20: note: in definition of macro 
'__SC_DELOUSE'
 (t)(__TYPE_IS_PTR(t) ? ((v) & 0x7fff) : (v)); \
   ^
>> include/linux/syscalls.h:44:22: note: in expansion of macro '__MAP6'
#define __MAP(n,...) __MAP##n(__VA_ARGS__)
 ^
>> include/linux/compat.h:54:23: note: in expansion of macro '__MAP'
  return C_SYSC##name(__MAP(x,__SC_DELOUSE,__VA_ARGS__)); \
  ^
>> include/linux/compat.h:45:2: note: in expansion of macro 
>> 'COMPAT_SYSCALL_DEFINEx'
 COMPAT_SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
 ^
   fs/notify/fanotify/fanotify_user.c:913:1: note: in expansion of macro 
'COMPAT_SYSCALL_DEFINE6'
COMPAT_SYSCALL_DEFINE6(fanotify_mark,
^
   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/uapi/linux/fanotify.h:4,
from include/linux/fanotify.h:4,
from fs/notify/fanotify/fanotify_user.c:1:
   fs/notify/fanotify/fanotify_user.c:914:23: error: expected expression before 
'unsigned'
int, fanotify_fd, unsigned int, flags,