[PATCH v06 14/36] arm uapi asm/signal.h: include <stddef.h> for size_t in userspace

[PATCH v06 14/36] arm uapi asm/signal.h: include <stddef.h> for size_t in userspace

[Mikko Rapeli]

Arnd Bergmann <arnd@arndb.de> doubts that __kernel_size_t could be used here
so trying to fall back to gcc's <stddef.h>.

Fixes uapi header compilation error from userspace on ARCH=arm:

asm/signal.h:112:2: error: unknown type name ?size_t?
  size_t ss_size;

Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
Cc: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/include/uapi/asm/signal.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/include/uapi/asm/signal.h b/arch/arm/include/uapi/asm/signal.h
index 33073bdcf091..63066f624c10 100644
--- a/arch/arm/include/uapi/asm/signal.h
+++ b/arch/arm/include/uapi/asm/signal.h
@@ -12,6 +12,8 @@ struct siginfo;
 #define NSIG		32
 typedef unsigned long sigset_t;
 
+#include <stddef.h>
+
 #endif /* __KERNEL__ */
 
 #define SIGHUP		 1
-- 
2.13.3

[PATCH v06 14/36] arm uapi asm/signal.h: include <stddef.h> for size_t in userspace

[Dmitry V. Levin]

On Sun, Aug 06, 2017 at 06:44:05PM +0200, Mikko Rapeli wrote:
> Arnd Bergmann <arnd@arndb.de> doubts that __kernel_size_t could be used here
> so trying to fall back to gcc's <stddef.h>.

The only architecture where you cannot do this safely is x86 family
because of x32 exception.  If there is no chance that the change will
affect x32, feel free to replace size_t with __kernel_size_t like I did
some time ago, see
http://lkml.kernel.org/r/20170302002022.GB27097 at altlinux.org


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170809/e5fabc5a/attachment.sig>

[PATCH v06 05/36] uapi linux/sysctl.h: use __kernel_size_t instead of size_t

[Mikko Rapeli]

Hi Dmitry and thanks for the comments.

I have only one question: why haven't your patches been applied yet?

-Mikko

[PATCH v06 14/36] arm uapi asm/signal.h: include <stddef.h> for size_t in userspace

[Arnd Bergmann]

On Wed, Aug 9, 2017 at 12:57 AM, Dmitry V. Levin <ldv@altlinux.org> wrote:
> On Sun, Aug 06, 2017 at 06:44:05PM +0200, Mikko Rapeli wrote:
>> Arnd Bergmann <arnd@arndb.de> doubts that __kernel_size_t could be used here
>> so trying to fall back to gcc's <stddef.h>.
>
> The only architecture where you cannot do this safely is x86 family
> because of x32 exception.  If there is no chance that the change will
> affect x32, feel free to replace size_t with __kernel_size_t like I did
> some time ago, see
> http://lkml.kernel.org/r/20170302002022.GB27097 at altlinux.org

There is another problem: on some 32-bit architectures, size_t is
defined as 'unsigned int', while '__kernel_size_t' is defined as 'unsigned
long'. These obviously have the same size, but the man page
explicitly defines it as 'size_t ss_size'.

If a user space program accesses the field in a way requires an
exact type match, it gets a warning or error, e.g.

1. printf("signal with %zd bytes\n", stack->ss_size);
2. size_t *pointer_to_size_t = &stack->ss_size;
3. assert(__builtin_types_compatible_p(size_t, typeof(stack->ss_size)))

Not sure how important those are, but I think there is at least a risk
of any of those showing up in user space.

         Arnd

[PATCH v06 14/36] arm uapi asm/signal.h: include <stddef.h> for size_t in userspace

[Dmitry V. Levin]

On Wed, Aug 09, 2017 at 02:41:59PM +0200, Arnd Bergmann wrote:
> On Wed, Aug 9, 2017 at 12:57 AM, Dmitry V. Levin <ldv@altlinux.org> wrote:
> > On Sun, Aug 06, 2017 at 06:44:05PM +0200, Mikko Rapeli wrote:
> >> Arnd Bergmann <arnd@arndb.de> doubts that __kernel_size_t could be used here
> >> so trying to fall back to gcc's <stddef.h>.
> >
> > The only architecture where you cannot do this safely is x86 family
> > because of x32 exception.  If there is no chance that the change will
> > affect x32, feel free to replace size_t with __kernel_size_t like I did
> > some time ago, see
> > http://lkml.kernel.org/r/20170302002022.GB27097 at altlinux.org
> 
> There is another problem: on some 32-bit architectures, size_t is
> defined as 'unsigned int', while '__kernel_size_t' is defined as 'unsigned
> long'. These obviously have the same size, but the man page
> explicitly defines it as 'size_t ss_size'.
> 
> If a user space program accesses the field in a way requires an
> exact type match, it gets a warning or error, e.g.
> 
> 1. printf("signal with %zd bytes\n", stack->ss_size);
> 2. size_t *pointer_to_size_t = &stack->ss_size;
> 3. assert(__builtin_types_compatible_p(size_t, typeof(stack->ss_size)))
> 
> Not sure how important those are, but I think there is at least a risk
> of any of those showing up in user space.

Agreed, one has to take this issue into consideration when replacing
size_t with __kernel_size_t.


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170809/662ed8f2/attachment.sig>