linux-kernel - Re: [2/6] uaccess: add probe_kernel

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.1.00.0802101102300.2896@woody.linux-foundation.org>
Date:	Sun, 10 Feb 2008 11:12:19 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jan Kiszka <jan.kiszka@....de>
cc:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@....com.au>,
	Thomas Gleixner <tglx@...utronix.de>,
	Jason Wessel <jason.wessel@...driver.com>
Subject: Re: [2/6] uaccess: add probe_kernel_write()

On Sun, 10 Feb 2008, Jan Kiszka wrote:
> 
> Along Linus' suggestion to work on larger chunks in kgdb, here are
> improved probe_kernel_read/write helpers that take a size argument.

I don't think this is good.

Make it
 - a function, not a #define
 - preferably uninlined (this does *not* look performance-critical)
 - get rid of the get_fs/set_fs/set_fs dance

The last point is somewhat debatable, but the fact is, those functions are 
not defined to be safe to be called from interrupt context. And since we 
use the "__copy_xxxx()" functions with two underscores, those really are 
supposed to mean that we've checked the address earlier.

So it's possible that some architecture does need the explicit segment 
munging (S390 comes to mind), but in that case, we really should add 
special support for that, or we should really validate that get_fs/set_fs 
are safe in all contexts.

And regardless, if we *do* end up needing to munge some segment register 
(which on other architectures tends to be an address space identifier, not 
a segment, but whatever), that just makes it even more clear that this 
isn't some macro or inline function, because those things tend to explode 
the code-space.

			Linus
--
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/