From: Andrew Morton <akpm@osdl.org>
To: ebiederm@xmission.com (Eric W. Biederman)
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] i386: Add a temporary to make put_user more type safe.
Date: Sat, 28 Jan 2006 22:39:17 -0800 [thread overview]
Message-ID: <20060128223917.4e5c3dd9.akpm@osdl.org> (raw)
In-Reply-To: <m1r76rft2t.fsf@ebiederm.dsl.xmission.com>
ebiederm@xmission.com (Eric W. Biederman) wrote:
>
>
> In some code I am developing I had occasion to change the type of a
> variable. This made the value put_user was putting to user space
> wrong. But the code continued to build cleanly without errors.
What do you mean by "wrong"? What combinations of types do you think
should be disallowed here? put_user(char, int*), for example, or what?
We had one instance recently where code was doing put_user() of an
eight-byte struct and that sailed through x86 testing but made the sparc64
compiler ICE. Certainly we should stamp out tricks like that at compile
time, but how far should we go?
There's probably a good case for ensuring that typeof(x)==typeof(*ptr), but
I suspect that'd create a lot of noise.
> Introducing a temporary fixes this problem and at least with gcc-3.3.5
> does not cause gcc any problems with optimizing out the temporary.
> gcc-4.x using SSA internally ought to be even better at optimizing out
> temporaries, so I don't expect a temporary to become a problem.
> Especially because in all correct cases the types on both sides of the
> assignment to the temporary are the same.
>
Sounds sane. We could make it warn if typeof(x)!=typeof(*ptr) by adding
another temporary for the pointer, give it type typeof(x)*, but I haven't
tried it.
>
>
> ---
>
> include/asm-i386/uaccess.h | 11 ++++++-----
> 1 files changed, 6 insertions(+), 5 deletions(-)
>
> dd1215e541bfe2ed94a902f7fb263ca44b7e8afa
> diff --git a/include/asm-i386/uaccess.h b/include/asm-i386/uaccess.h
> index 3f1337c..1641613 100644
> --- a/include/asm-i386/uaccess.h
> +++ b/include/asm-i386/uaccess.h
> @@ -198,12 +198,13 @@ extern void __put_user_8(void);
> #define put_user(x,ptr) \
> ({ int __ret_pu; \
> __chk_user_ptr(ptr); \
> + __typeof__(*(ptr)) __pu_val = x; \
> switch(sizeof(*(ptr))) { \
> - case 1: __put_user_1(x, ptr); break; \
> - case 2: __put_user_2(x, ptr); break; \
> - case 4: __put_user_4(x, ptr); break; \
> - case 8: __put_user_8(x, ptr); break; \
> - default:__put_user_X(x, ptr); break; \
> + case 1: __put_user_1(__pu_val, ptr); break; \
> + case 2: __put_user_2(__pu_val, ptr); break; \
> + case 4: __put_user_4(__pu_val, ptr); break; \
> + case 8: __put_user_8(__pu_val, ptr); break; \
> + default:__put_user_X(__pu_val, ptr); break; \
> } \
> __ret_pu; \
> })
> --
> 1.1.5.g3480
next prev parent reply other threads:[~2006-01-29 6:39 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-29 6:26 Eric W. Biederman
2006-01-29 6:39 ` Andrew Morton [this message]
2006-01-29 6:49 ` Eric W. Biederman
2006-01-29 7:51 ` Andrew Morton
[not found] ` <200601291620.28291.ioe-lkml@rameria.de>
2006-01-29 19:33 ` Andrew Morton
2006-01-29 20:04 ` [PATCH] i386: instead of poisoning .init zone, change protection bits to force a fault Eric Dumazet
2006-01-29 20:05 ` Benjamin LaHaise
2006-01-29 20:28 ` Eric Dumazet
2006-01-29 20:56 ` [PATCH, V2] " Eric Dumazet
2006-01-30 9:03 ` Questions about alloc_large_system_hash() and TLB entries Eric Dumazet
2006-01-30 9:22 ` David S. Miller
2006-01-30 10:22 ` Eric Dumazet
2006-02-04 22:41 ` [PATCH, V2] i386: instead of poisoning .init zone, change protection bits to force a fault Andrew Morton
2006-02-05 17:03 ` Eric Dumazet
2006-02-05 19:42 ` Andrew Morton
2006-02-06 8:53 ` Eric Dumazet
2006-02-06 9:02 ` Eric Dumazet
2006-02-06 9:28 ` Andrew Morton
2006-02-06 10:07 ` Eric Dumazet
2006-02-06 10:16 ` Andrew Morton
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=20060128223917.4e5c3dd9.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome