linux-kernel - Re: access

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <200907151527.08341.arnd@arndb.de>
Date:	Wed, 15 Jul 2009 15:27:07 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Ralf Baechle <ralf@...ux-mips.org>
Cc:	John Williams <jwilliams@...e.uq.edu.au>, monstr@...str.eu,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	LTP <ltp-list@...ts.sourceforge.net>
Subject: Re: access_ok macor

On Wednesday 15 July 2009, Ralf Baechle wrote:

> > I think in step 4. AFIACT, the kernel must do a number of checks on accesses
> > to random pointers.
>
> Yes; but the checks that unaligned.c does on MIPS are no different from
> any other get_user(), that is it ensures that the entire 8/16/32/64-bit
> access is in userspace.  That's done using access_ok().

Well, access_ok() plus the fixup code for unmapped or write-protected user
pages, I guess. But I agree, there are no checks beyond what get/put_user
does. In particular, the access_ok() check should only be needed for
faults from user space, while any fault coming from kernel space is
either some kernel code accessing its own data (as you mention below) or
a __get_user/__put_user that has already checked access permissions.

In my example, I got the case from kernel space wrong, it should not
check access_ok() if !user_space(regs), or it needs to do set_fs(KERNEL_DS)
first, like the mips code does.

> We've moved on.  Handling miss-alignment is no longer a very relavent part
> of the syscall interface.  So I think for the definition of the Linux
> ABI this should just be left as implementation defined behaviour but
> whatever an architecture does, it should be done consistently for all
> system interfaces.

Ok, thanks, for explanation.

I guess for the microblaze unaligned handler, both cases mean that
it needs to do a fixup table lookup for the original fault and
it needs to handle fixups on its own emulation code. The only difference
between disallowing unaligned accesses in the ABI and allowing them
is which of the two ways (check fixup table, emulate instruction) it
tries first.

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