Re: access_ok macor

Arnd Bergmann wrote:
On Tuesday 14 July 2009, Michal Simek wrote:
I found that I can setup text base in binutils/ld/emulparam/elf32mb_linux.sh

The problem which I have is that if I run socketpair, getsockname, getpeername LTP
tests with invalid salen pointer there are addresses close to 0x0. Microblaze
has no text there and the sigsegv fault is generated.

This sounds like a classic NULL pointer dereference that is handled correctly
by the kernel. The question is where the address came from.

It is not anly NULL pointer - is LTP tests are some fake addresses. From my tests I see
that I am not able to access place till 1000 0000 in dec.
Bad address come from tests to test it.

Look at
http://developer.petalogix.com/git/gitweb.cgi?p=ltp-microblaze.git;a=commitdiff;h=45f4cd783ce8b94f1267bb87c0c46e8536f62eca

There are three affected tests and my quick fixes which I am trying to solve now.



This fault could be fixed by changed access_ok macro where I check bottom limit
at 0x1000 0000 too. After this change the LTP program not failed but I am not sure
if is the right solution because none arch do it. All archs just check upper limit
not lower.

What is the correct solution for it? Moving .text base to 0x0 or is there any other
elegant solution?

Moving .text is not the right solution, because it only papers over real bugs.

I can confirm it - I moved it and rebuild toolchain.

access_ok() is also not the right place to check this, the only purpose it has
is to make sure that the argument is not a valid kernel address but either a
valid user address or possibly invalid address. Also, access_ok() is only used
together with the copy_from/to_user and get/put_user function families. These
need to catch invalid addresses with a fixup table entry in the kernel.

ok - that mean that problem could be in bad fixup table?



I briefly looked at your implementation but could not find any problems in
this area. Could you use gdb to find out whether the sigsegv happens in the
kernel at all, or in user space?

We don't have gdb in place.

The problem should come from get_user macro. net/socket.c:212
I was looking for it in the morning. I am checking it again.

Thanks,
Michal


int move_addr_to_user(struct sockaddr *kaddr, int klen, void __user *uaddr,
int __user *ulen)
{
int err;
int len;

err = get_user(len, ulen);
if (err)
return err;



Arnd <><


--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: null references
    ... To say that null and invalid references don't exist suggests that if you would just change to the function would be unable to fail and therefore correctly manages the semaphore, but this is a bogus argument. ... The reference version of the function can still throw an access violation and still needs to be coded for exception safety. ... If you define the above function as taking a reference arg then the undefined behaviour occurs the moment someone tries to dereference an invalid pointer. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: interpreting a null pointer as an empty (null string)
    ... there requires doing something that has undefined behavior (or, at least, ... which is the usual destination of the null pointer. ... Looks like this is explicitly disallowed by the Standard, ... null pointers being "invalid" as operands of the indirection operator; ...
    (comp.lang.c)
  • Re: C Standard Regarding Null Pointer Dereferencing
    ... possible case in which a pointer *has* an invalid value. ... evaluation of the expression '*0', ... You and other kind responders have been deducting. ...
    (comp.lang.c)
  • Re: null references
    ... invalid to cause an access violation, ... The reference version of the function can still throw an access ... obtained by dereferencing a null pointer which causes undefined behaviour". ... occurs before the function has even started so how can it protect itself. ...
    (microsoft.public.dotnet.languages.csharp)