Re: [PATCH] mm: kill kmemcheck
On Wed, Mar 11, 2015 at 09:39:33AM -0400, Sasha Levin wrote: > On 03/11/2015 08:40 AM, Steven Rostedt wrote: > > On Wed, 11 Mar 2015 08:34:46 -0400 > > Sasha Levin wrote: > > > >> > Fair enough. We knew there are existing kmemcheck users, but KASan > >> > should be > >> > superior both in performance and the scope of bugs it finds. It also > >> > shouldn't > >> > impose new limitations beyond requiring gcc 4.9.2+. > >> > > > Ouch! OK, then I can't use it. I'm currently compiling with gcc 4.6.3. > > > > It will be a while before I upgrade my build farm to something newer. > > Are you actually compiling new kernels with 4.6.3, or are you using older > kernels as well? > > There's no real hurry to kill kmemcheck right now, but we do want to stop > supporting that in favour of KASan. Another question is "is kmemcheck actually finding anything right now?" I've personally not hit anything with it in quite a while. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: General flags to turn things off (getrandom, pid lookup, etc)
On Fri, Jul 25, 2014 at 11:30:48AM -0700, Andy Lutomirski wrote: > There is recent interest in having a way to turn generally-available > kernel features off. Maybe we should add a good one so we can stop > bikeshedding and avoid proliferating dumb interfaces. > > Things that might want to be turn-off-able include: > - getrandom with GRND_RANDOM [from the getrandom threads] > - Any lookup of a non-self pid [from the capsicum thread] > - Any lookup of a pid outside the caller thread group [capsicum] > - Various architectural things (personal wishlist), e.g.: > - RDTSC and userspace HPET access > - CPUID? > - 32-bit GDT code segments [huge attack surface] > - 64-bit GDT code segments [probably pointless] I'm not sure there's value in disabling cpuid dev interface, when the instruction is unprivileged. > I would propose a new syscall for this: > > long restrict_userspace(int mode, int type, int value, int flags); do the restrictions happen system-wide like in say SELinux, or only within the calling process, like seccomp ? Dave -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GPF in aesni_xts_crypt8 (3.10-rc5)
On Tue, Jun 11, 2013 at 10:01:01PM +0300, Jussi Kivilinna wrote: > Hello, > > Does attached patch help? > > crypto: aesni_intel - fix accessing of unaligned memory It does, thanks for the quick turnaround! Dave -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Thu, Feb 15, 2007 at 10:13:04PM +, Pavel Machek wrote: > Hi! > > > Now, this is not a complete solution by any means: the core kernel is not > > protected, and nor are /dev/mem or /dev/kmem, but it denies (or at least > > controls) one relatively simple attack vector. > > Could we fix the /dev/*mem holes, first? They are already used by > malicious modules (aka rootkits...). Or can selinux already provide > /dev/*mem protection with no way for admin to turn it off? There are some valid uses for peeking through /dev/mem. Things like dmidecode for example. So you don't want to disable it completely in a lot of cases, but have fine-grained access to specific parts of the file. I'm not sure SELinux can do this. Maybe the MLS stuff helps here (though I'm far from an expert on this, so I could be talking out of my rear). The restricted dev/mem patches we've had in Fedora for a while do the right thing, but they're a bit crufty (in part due to drivers/char/mem.c being a bit of a mess before we even start patching it). I've had "clean these up for upstream" on my todo for a while. I might get around to it one of these days. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Wed, Feb 14, 2007 at 10:14:53PM -0800, Andreas Gruenbacher wrote: > On Wednesday 14 February 2007 21:45, Dave Jones wrote: > > well, the situation for external modules is no worse than usual. > > They still work, they just aren't signed. Which from a distributor point > > of view, is actually a nice thing, as they stick out like a sore thumb > > in oops reports with (U) markers :) > > I agree, that's really what should happen. We solve this by marking modules > as > supported, partner supported, or unsupported, but in an "insecure" way, so > partners and users could try to fake the support status of a module and/or > remove status flags from Oopses, and cryptography wouldn't save us. We could > try to sign Oopses which I guess you guys are doing. This whole issue hasn't > been a serious problem in the past though, and we generally try to trust > users not to play games on us. For the most part it works out. I've had users file oopses where they've editted out Tainted: P, and left in nvidia(U) for example :-) Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Wed, Feb 14, 2007 at 09:35:40PM -0800, Andreas Gruenbacher wrote: > On Wednesday 14 February 2007 20:13, Dave Jones wrote: > > I've not investigated it, but I hear rumours that suse has something > > similar. > > Actually, no. We don't belive that module signing adds significant value, ok, then I was misinformed. > and it also doesn't work well with external modules. well, the situation for external modules is no worse than usual. They still work, they just aren't signed. Which from a distributor point of view, is actually a nice thing, as they stick out like a sore thumb in oops reports with (U) markers :) > (The external modules we really care about are GPL ones; it gives us a way > to update drivers without pushing out entirely new kernels.) external modules still compile, and run just fine. The signed modules code doesn't prevent loading of them unless the user decides to do so with a special boot option (which is no different really than say, reducing the cap-bound sysctl to prevent module loading). Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Wed, Feb 14, 2007 at 07:41:12PM -0800, Andrew Morton wrote: > 77 files changed, 9681 insertions(+), 10 deletions(-) > > just to be able to sign modules. > > Normally I'd collapse writhing in laughter, but.. > > > These patches have been in use by RHEL and Fedora kernels for years, and so > > have been thoroughly tested. > > so I guess there's an argument for merging them so we can send them back to > you guys. But there's also an argument to declare all this gunk a > vendor-only thing. How much pain would that cause? it needs rediffing pretty much every time the cryptoapi changes. On a good month that means once per point release, otherwise... One argument in its favour is aparently Red Hat isn't the only vendor with something like this. I've not investigated it, but I hear rumours that suse has something similar. Having everyone using the same code would be a win for obvious reasons. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
