paper help - 未名空间MITBBS历史存档

国际科技财经博客移民网络热点娱乐民生时事公众号

Redian新闻

>未名空间

>Chemistry - 化学

paper help

paper help# Chemistry - 化学

h*c2011-09-12 07:09

1 楼

大家提前多久申请延期啊?看了一圈还是糊涂

w*82011-09-12 07:09

2 楼

大家有没有学/考一些相关的证书(certificate)给自己冲电,即使如果现在的工作用不
着? six sigma, project management... 看到有很多online programs, 有没有人能推
荐靠谱的? 谢谢

i*p2011-09-12 07:09

3 楼

【以下文字转载自 Linux 讨论区】
发信人: isup (No), 信区: Linux
标题: copy_from_user() 是怎么知道缓存长度的？
发信站: BBS 未名空间站 (Thu May 1 00:42:13 2014, 美东)
先看这个函数的定义。
-------------------------
unsigned long copy_from_user(void *to, const void __user *from, unsigned
long count);
the return value is the amount of memory still to be copied.
-------------------------
to 是由kmalloc()分配的kernel内存空间，假定512字节。
from 是存有数据的内存，其长度是 count 字节。假定是612字节。
这个函数的返回值是612-512=100，the amount of memory still to be copied。
我的问题是copy_from_user() 执行时，它是怎么知道得"to"的大小呢?

b*e2011-09-12 07:09

4 楼

Structure of CrIIF(NCMe)2BF4. Rietveld refinement of a component of a
physical mixture of unknown composition
CrystEngComm, 2008, 10, 1728-1730
Preparation and structure of View the [Cr2IIIF3(TPyA)2](BF4)3 [TPyA = tris(2
-pyridylmethyl)amine] possessing terminal and bridging fluorides
Inorganica Chimica Acta
Volume 362, Issue 2, 20 January 2009, Pages 595-598
please send pdf file to b*******[email protected]
Many thanks and bow~

t*s2011-09-12 07:09

5 楼

批准一般1－3个月。只要交上去，等待期间都是合法。
太早了也不好。

r*r2011-09-12 07:09

6 楼

公司会有这个培训的
而且每个公司涉及到具体流程都会有点不一样

【在 w*****8 的大作中提到】

: 大家有没有学/考一些相关的证书(certificate)给自己冲电,即使如果现在的工作用不
: 着? six sigma, project management... 看到有很多online programs, 有没有人能推
: 荐靠谱的? 谢谢

j*a2011-09-12 07:09

7 楼

__Context__
User context only. This function may sleep.
__Description__
Copy data from user space to kernel space.
Returns number of bytes that could not be copied. On success, this will be
zero.
If some data could not be copied, this function will pad the copied data to
the requested size using zero bytes.

【在 i**p 的大作中提到】

: 【以下文字转载自 Linux 讨论区】
: 发信人: isup (No), 信区: Linux
: 标题: copy_from_user() 是怎么知道缓存长度的？
: 发信站: BBS 未名空间站 (Thu May 1 00:42:13 2014, 美东)
: 先看这个函数的定义。
: -------------------------
: unsigned long copy_from_user(void *to, const void __user *from, unsigned
: long count);
: the return value is the amount of memory still to be copied.
: -------------------------

W*e2011-09-12 07:09

8 楼

1,
http://www.sendspace.com/file/dyfeib

i*p2011-09-12 07:09

9 楼

"Returns number of bytes that could not be copied"
This is my question. How does the function know the size of kernel space in
order to return the number of bytes that could not be copied?

to

【在 j*a 的大作中提到】

: __Context__
: User context only. This function may sleep.
: __Description__
: Copy data from user space to kernel space.
: Returns number of bytes that could not be copied. On success, this will be
: zero.
: If some data could not be copied, this function will pad the copied data to
: the requested size using zero bytes.

W*e2011-09-12 07:09

10 楼

2,
http://www.sendspace.com/file/auv1pw

j*a2011-09-12 07:09

11 楼

(deleted as it doesn't make sense to me)

in

【在 i**p 的大作中提到】

: "Returns number of bytes that could not be copied"
: This is my question. How does the function know the size of kernel space in
: order to return the number of bytes that could not be copied?
:
: to

S*A2011-09-12 07:09

12 楼

It only verify the "from" pointer. Because the "from" is pass by
the user space program. It might be an invalid pointer, or pointer
haven't mmap to any memory.
The "to" pointer is not validated at all. It will assume the "to"
memory buffer is big enough. If not. It will corrupt memory (likely)
or generate kernel panic(unlikely).

【在 i**p 的大作中提到】

i*p2011-09-12 07:09

13 楼

the 3rd parameter, count, is the size of the user space. No size of the
kernel space. And the size of the kernel space can be smaller than user
space. that is why un-copied amount will be returned.
how does kernel "make sure there's enough space"?

【在 j*a 的大作中提到】

: (deleted as it doesn't make sense to me)
:
: in

S*A2011-09-12 07:09

14 楼

So the rule of game is that, it is up to the caller of copy_from_user()
to make sure the "to" buffer is big enough. It is a serious error if
the caller did not guarantee that.

S*A2011-09-12 07:09

15 楼

I answer that in post #5. The kernel don't validate that.
It is the caller's job to make sure don't blow up the kernel
memory.

【在 i**p 的大作中提到】

: the 3rd parameter, count, is the size of the user space. No size of the
: kernel space. And the size of the kernel space can be smaller than user
: space. that is why un-copied amount will be returned.
: how does kernel "make sure there's enough space"?

j*a2011-09-12 07:09

16 楼

i deleted my post as it doesn't make sense.

【在 i**p 的大作中提到】

j*a2011-09-12 07:09

17 楼

or check stackoverflow.

【在 S*A 的大作中提到】

: I answer that in post #5. The kernel don't validate that.
: It is the caller's job to make sure don't blow up the kernel
: memory.

i*p2011-09-12 07:09

18 楼

Are you sure?
My understand is "to" can be smaller than "from". That is why to return
number of bytes that could not be copied in the case.

【在 S*A 的大作中提到】

: It only verify the "from" pointer. Because the "from" is pass by
: the user space program. It might be an invalid pointer, or pointer
: haven't mmap to any memory.
: The "to" pointer is not validated at all. It will assume the "to"
: memory buffer is big enough. If not. It will corrupt memory (likely)
: or generate kernel panic(unlikely).

S*A2011-09-12 07:09

19 楼

or check the kernel source code. Only a few function
call to go through.

【在 j*a 的大作中提到】

: or check stackoverflow.

i*p2011-09-12 07:09

20 楼

That is another way to understand it. We can save time if people here know
the answer.

【在 S*A 的大作中提到】

: or check the kernel source code. Only a few function
: call to go through.

S*A2011-09-12 07:09

21 楼

I am pretty sure. The return number of bytes indicate the end of
buffer condition in the "from", not the "to". Even if the "from" buffer
is smaller than the size requested, the rest is padding to 0 into the
"to" buffer.
Look at the source code. __copy_from_user()
Context: User context only. This function may sleep.
*
* Copy data from user space to kernel space. Caller must check
* the specified block with access_ok() before calling this function.
*
* Returns number of bytes that could not be copied.
* On success, this will be zero.
*
* If some data could not be copied, this function will pad the copied
* data to the requested size using zero bytes.
*

【在 i**p 的大作中提到】

: Are you sure?
: My understand is "to" can be smaller than "from". That is why to return
: number of bytes that could not be copied in the case.

S*A2011-09-12 07:09

22 楼

I already told you. You just like to second guess my answer :-)

【在 i**p 的大作中提到】

: That is another way to understand it. We can save time if people here know
: the answer.

i*p2011-09-12 07:09

23 楼

"Returns number of bytes that could not be copied."
Could you give me an example when this happens? My understanding is that "to
" smaller than "from". yes, in general we will see a crash. However, it
seems the kernel "knows" that and processes it well.

【在 S*A 的大作中提到】

: I am pretty sure. The return number of bytes indicate the end of
: buffer condition in the "from", not the "to". Even if the "from" buffer
: is smaller than the size requested, the rest is padding to 0 into the
: "to" buffer.
: Look at the source code. __copy_from_user()
: Context: User context only. This function may sleep.
: *
: * Copy data from user space to kernel space. Caller must check
: * the specified block with access_ok() before calling this function.
: *

t*r2011-09-12 07:09

24 楼

LZ,
write a small kernel module. compile it and run it.
kmalloc smaller size than what you want to copy from user to kernel. call it
. see if kernel crash or oops or core-dump.
Then you will understand.
Also, this copy_from_user is architecture dependent implementation.
You don't need to think too much about it.
When you write kernel module or kernel code. always make sure you kmalloc
enough space.then there is no problem.
From man page, sounds like you should never copy more bytes from user space
to kernel space than waht you kmalloc-ed in kernel.

S*A2011-09-12 07:09

25 楼

regarding returning "non copied length".
As you can see in the source. When the "from" pointer is
NOT ok to read. It will return the original size n.
unsigned long
copy_from_user(void *to, const void __user *from, unsigned long n)
{
if (access_ok(VERIFY_READ, from, n))
n = __copy_from_user(to, from, n);
else
memset(to, 0, n);
return n;
}

S*A2011-09-12 07:09

26 楼

If you do ioctl, pass an invalid user space pointer.
That will cause access validation fail.
In that case it will return the full size n. All buffer is bad
and the "to" buffer has memset to 0.
The kernel should not panic a user space program because
they send wrong pointers. The kernel should return error
in the ioctl. It is bad that user space panic on sending kernel
wrong pointer.

to

【在 i**p 的大作中提到】

: "Returns number of bytes that could not be copied."
: Could you give me an example when this happens? My understanding is that "to
: " smaller than "from". yes, in general we will see a crash. However, it
: seems the kernel "knows" that and processes it well.

i*p2011-09-12 07:09

27 楼

I had read it. This is not enough. We need to read _copy_from_user() to
understand how kernel checks size of "to".

【在 S*A 的大作中提到】

: regarding returning "non copied length".
: As you can see in the source. When the "from" pointer is
: NOT ok to read. It will return the original size n.
: unsigned long
: copy_from_user(void *to, const void __user *from, unsigned long n)
: {
: if (access_ok(VERIFY_READ, from, n))
: n = __copy_from_user(to, from, n);
: else
: memset(to, 0, n);

i*p2011-09-12 07:09

28 楼

This is what I read. There is no "memset(to, 0, n);"
255 static inline long copy_from_user(void *to,
256 const void __user * from, unsigned long n)
257 {
258 might_fault();
259 if (access_ok(VERIFY_READ, from, n))
260 return __copy_from_user(to, from, n);
261 else
262 return n;
263 }
http://lxr.free-electrons.com/source/include/asm-generic/uacces

【在 S*A 的大作中提到】

S*A2011-09-12 07:09

29 楼

Actually. If you read copy_user_64.S
The asm version will just do a copy and if the exception happen.
It will recover and stop the copy.
So I was wrong about "to" can generate exception. It don't
because the asm function contain the exception. But it will
still happily corrupt the "to" buffer if the "to" buffer is too
small and beyond the "to" buffer is writable.

【在 i**p 的大作中提到】

: I had read it. This is not enough. We need to read _copy_from_user() to
: understand how kernel checks size of "to".

S*A2011-09-12 07:09

30 楼

Your code is newer than mine. The machine I am using
has a very old kernel git tree.

【在 i**p 的大作中提到】

: This is what I read. There is no "memset(to, 0, n);"
: 255 static inline long copy_from_user(void *to,
: 256 const void __user * from, unsigned long n)
: 257 {
: 258 might_fault();
: 259 if (access_ok(VERIFY_READ, from, n))
: 260 return __copy_from_user(to, from, n);
: 261 else
: 262 return n;
: 263 }

i*p2011-09-12 07:09

31 楼

Thanks for your findings. Is it a bug?

【在 S*A 的大作中提到】

: Actually. If you read copy_user_64.S
: The asm version will just do a copy and if the exception happen.
: It will recover and stop the copy.
: So I was wrong about "to" can generate exception. It don't
: because the asm function contain the exception. But it will
: still happily corrupt the "to" buffer if the "to" buffer is too
: small and beyond the "to" buffer is writable.

S*A2011-09-12 07:09

32 楼

It is not a bug. It is just the way it is. Call it
a feature as you like.
Kernel code is not as forgiving as the user space code.
Because kernel care performance very much. It will
let the caller to take the responsibility to maintain the
buffer. That part is still true as I said earlier.
If you want to shoot yourself in the foot from
the kernel. The kernel will gladly let you do so.

【在 i**p 的大作中提到】

: Thanks for your findings. Is it a bug?

i*p2011-09-12 07:09

33 楼

From the description of the function that "the return value is the amount of
memory still to be copied.", it seems the function is able to process "to"
smaller than "from".
The bug I mentioned is what you find that "the 'to' buffer is too
small and beyond the 'to' buffer is writable."
Is possible the kernel has some way to guarantee that beyond the 'to' buffer
is NEVER writable?

【在 S*A 的大作中提到】

: It is not a bug. It is just the way it is. Call it
: a feature as you like.
: Kernel code is not as forgiving as the user space code.
: Because kernel care performance very much. It will
: let the caller to take the responsibility to maintain the
: buffer. That part is still true as I said earlier.
: If you want to shoot yourself in the foot from
: the kernel. The kernel will gladly let you do so.

S*A2011-09-12 07:09

34 楼

Your "seems" was wrong understanding.
That is not a bug. That is a user error.
There is no way to limit the access beyond the "to" buffer.
If you give "to" from a page, only 512 bytes.
The rest of the page is writable. The kernel linear map all
the memory in kernel space, in x86_64 there is not 4G address
space limit, all the memory does fit.
There for the "to" pointer is very likely part of that linear map.

of
"
buffer

【在 i**p 的大作中提到】

: From the description of the function that "the return value is the amount of
: memory still to be copied.", it seems the function is able to process "to"
: smaller than "from".
: The bug I mentioned is what you find that "the 'to' buffer is too
: small and beyond the 'to' buffer is writable."
: Is possible the kernel has some way to guarantee that beyond the 'to' buffer
: is NEVER writable?
:

i*p2011-09-12 07:09

35 楼

The key is how to understand this --
"the return value is the amount of memory still to be copied. "
My understanding might be wrong. Could you let me know your understanding to
it? And what case will it happen in?

【在 S*A 的大作中提到】

: Your "seems" was wrong understanding.
: That is not a bug. That is a user error.
: There is no way to limit the access beyond the "to" buffer.
: If you give "to" from a page, only 512 bytes.
: The rest of the page is writable. The kernel linear map all
: the memory in kernel space, in x86_64 there is not 4G address
: space limit, all the memory does fit.
: There for the "to" pointer is very likely part of that linear map.
:
: of

S*A2011-09-12 07:09

36 楼

I already explain that to you.
It does not check the "to" pointer can write or not.
The failure case will cause return not zero.
The failure cause can be: page fault during
copy front the memory. If the page is not back
by any file or swapping device, it is a true page
fault and the copy will stop.
e.g. the user mmap 1 page and try to read 2 page size.
in that case the return value will be NONE zero.
If the "from" pointer does not have any memory backing
it at all. It will return the full length as failure value.

to

【在 i**p 的大作中提到】

: The key is how to understand this --
: "the return value is the amount of memory still to be copied. "
: My understanding might be wrong. Could you let me know your understanding to
: it? And what case will it happen in?