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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ