From: ldv@altlinux•org (Dmitry V. Levin)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v06 14/36] arm uapi asm/signal.h: include <stddef.h> for size_t in userspace
Date: Wed, 9 Aug 2017 15:52:35 +0300 [thread overview]
Message-ID: <20170809125235.GA19386@altlinux.org> (raw)
In-Reply-To: <CAK8P3a30Vd2JquMvZ88tTO4jFAUMJGtUpvLuDmDPp2UFBYXDLQ@mail.gmail.com>
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>
prev parent reply other threads:[~2017-08-09 12:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20170806164428.2273-1-mikko.rapeli@iki.fi>
2017-08-06 16:44 ` [PATCH v06 14/36] arm uapi asm/signal.h: include <stddef.h> for size_t in userspace Mikko Rapeli
2017-08-08 22:57 ` Dmitry V. Levin
[not found] ` <20170808225417.GE10552@altlinux.org>
[not found] ` <20170808225026.GD10552@altlinux.org>
[not found] ` <20170808224555.GC10552@altlinux.org>
[not found] ` <20170808224253.GB10552@altlinux.org>
[not found] ` <20170808223420.GA10552@altlinux.org>
2017-08-09 7:18 ` [PATCH v06 05/36] uapi linux/sysctl.h: use __kernel_size_t instead of size_t Mikko Rapeli
2017-08-09 12:41 ` [PATCH v06 14/36] arm uapi asm/signal.h: include <stddef.h> for size_t in userspace Arnd Bergmann
2017-08-09 12:52 ` Dmitry V. Levin [this message]
[not found] <20170808231711.GJ10552@altlinux.org>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170809125235.GA19386@altlinux.org \
--to=ldv@altlinux$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox