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

Groups > linux.kernel > #1210664 > unrolled thread

Re: [x86] copy_from{to}_user question

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: [x86] copy_from{to}_user question "H. Peter Anvin" <hpa@zytor.com> - 2015-08-20 20:30 +0200
    Re: [x86] copy_from{to}_user question Borislav Petkov <bp@suse.de> - 2015-08-21 06:40 +0200
      Re: [x86] copy_from{to}_user question "H. Peter Anvin" <hpa@zytor.com> - 2015-08-21 23:10 +0200
        Re: [x86] copy_from{to}_user question Borislav Petkov <bp@suse.de> - 2015-08-22 11:10 +0200
          Re: [x86] copy_from{to}_user question yalin wang <yalin.wang2010@gmail.com> - 2015-08-24 10:00 +0200
            Re: [x86] copy_from{to}_user question Jeff Epler <jepler@unpythonic.net> - 2015-08-24 14:10 +0200

#1210664 — Re: [x86] copy_from{to}_user question

On 08/16/2015 09:16 PM, Borislav Petkov wrote:
> On Mon, Aug 17, 2015 at 11:27:01AM +0800, yalin wang wrote:
>> i just want the x86 copy_from{to,in}_user() function have 
>> the same behaviour as other platforms.
> 
> Back to the original question from 2 mails ago:
> 
> How else would we be able to use the same function in copy_to and
> copy_from variants?
> 
>> and can disclose potential BUGs in kernel, if do like this.
> 
> Back to my other question:
> 
> Do you have any real life examples where you can trigger such bugs or is
> this only "potential"?
> 
> IOW, what I *think* you're trying to do sounds to me like unnecessary
> complication with no apparent gain *at* *all*. So show me why you want
> to do it: code it up, trigger a bug and show me why your version is
> better. No "but but it might be a good idea", no "potentially maybe",
> none of that maybe stuff. Write it, send it with instructions how
> someone else can apply it and trigger the issue. Ok?
> 

There is a valid reason to do this, which is that currently
copy_{to,from}_user() effectively bypass SMAP as they don't verify that
the kernel pointer is actually a kernel pointer.

The /proc/kcore issue is a completely different ball of wax, however.

	-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1210849

On Thu, Aug 20, 2015 at 11:22:43AM -0700, H. Peter Anvin wrote:
> There is a valid reason to do this, which is that currently
> copy_{to,from}_user() effectively bypass SMAP as they don't verify that
> the kernel pointer is actually a kernel pointer.

Well, we do STAC before we copy but SMAP is checking for supervisor
access to *user* data. But you say "kernel pointers" which is supervisor
data. What am I missing?

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1211331

On 08/20/2015 09:35 PM, Borislav Petkov wrote:
> On Thu, Aug 20, 2015 at 11:22:43AM -0700, H. Peter Anvin wrote:
>> There is a valid reason to do this, which is that currently
>> copy_{to,from}_user() effectively bypass SMAP as they don't verify that
>> the kernel pointer is actually a kernel pointer.
> 
> Well, we do STAC before we copy but SMAP is checking for supervisor
> access to *user* data. But you say "kernel pointers" which is supervisor
> data. What am I missing?
> 

What I'm saying is that we do do STAC, which *disables* SMAP.  We have
to do that because one pointer is known to be a user space pointer.

However, we currently don't verify that the *other* pointer is kernel
space, which it is supposed to be (if not, we should be using
copy_in_user).  We have to do this manually since we have to STAC which
means SMAP doesn't do anything at all.  I believe it would be a good
idea to add such checks (and they would even benefit non-SMAP hardware.)

	-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1211430

On Fri, Aug 21, 2015 at 02:06:16PM -0700, H. Peter Anvin wrote:
> What I'm saying is that we do do STAC, which *disables* SMAP.  We have
> to do that because one pointer is known to be a user space pointer.
> 
> However, we currently don't verify that the *other* pointer is kernel
> space, which it is supposed to be (if not, we should be using
> copy_in_user).  We have to do this manually since we have to STAC which
> means SMAP doesn't do anything at all.  I believe it would be a good
> idea to add such checks (and they would even benefit non-SMAP hardware.)

Ah, ok, so we're on the same page.

And yep, Linus gave the probe_kernel_read() suggestion in another mail.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1211874

> On Aug 22, 2015, at 17:05, Borislav Petkov <bp@suse.de> wrote:
> 
> On Fri, Aug 21, 2015 at 02:06:16PM -0700, H. Peter Anvin wrote:
>> What I'm saying is that we do do STAC, which *disables* SMAP.  We have
>> to do that because one pointer is known to be a user space pointer.
>> 
>> However, we currently don't verify that the *other* pointer is kernel
>> space, which it is supposed to be (if not, we should be using
>> copy_in_user).  We have to do this manually since we have to STAC which
>> means SMAP doesn't do anything at all.  I believe it would be a good
>> idea to add such checks (and they would even benefit non-SMAP hardware.)
> 
> Ah, ok, so we're on the same page.
> 
> And yep, Linus gave the probe_kernel_read() suggestion in another mail.
> 
i am not clear about what is STAC / SMAP ?
could you give me a link for understanding ?

Linus suggest to use probe_kernel_read() , but also said it is 
not efficient to use it, because we need copy the data 2 times by this method.

my patch suggests to use copy_in_user() ,
but seems not a generic(portable) function on all architectures.

Thanks--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1212100

On Mon, Aug 24, 2015 at 03:52:11PM +0800, yalin wang wrote:
> i am not clear about what is STAC / SMAP ?
> could you give me a link for understanding ?

the first item I found by googling was
https://lwn.net/Articles/517251/

Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web