Re: [PATCH v3] mm: add mremap flag for preserving the old mapping

On 30/09/14 01:49 PM, Andy Lutomirski wrote: I think it might pay to add an explicit vm_op to authorize duplication, especially for non-cow mappings. IOW this kind of extension seems quite magical for anything that doesn't have the normal COW semantics, including for plain old read-only

[PATCH v4] mm: add mremap flag for preserving the old mapping

and fragmentating memory over time is considered unacceptable. Signed-off-by: Daniel Micay danielmi...@gmail.com --- include/linux/huge_mm.h | 2 +- include/linux/mm.h| 6 ++ include/uapi/linux/mman.h | 1 + mm/huge_memory.c | 4 ++-- mm/memory.c | 2 +- mm

[PATCH v3] mm: add mremap flag for preserving the old mapping

end up blocking in-place growth with new allocations. The allocators could attempt to map the source location again after an mremap call, but there is no guarantee of success in a multi-threaded program and fragmentating memory over time is considered unacceptable. Signed-off-by: Daniel Micay

Re: [PATCH v3] mm: add mremap flag for preserving the old mapping

On 30/09/14 01:53 AM, Andy Lutomirski wrote: On Mon, Sep 29, 2014 at 9:55 PM, Daniel Micay danielmi...@gmail.com wrote: This introduces the MREMAP_RETAIN flag for preserving the source mapping when MREMAP_MAYMOVE moves the pages to a new destination. Accesses to the source location will fault

Re: [PATCH v3] mm: add mremap flag for preserving the old mapping

On 30/09/14 01:49 PM, Andy Lutomirski wrote: I think it might pay to add an explicit vm_op to authorize duplication, especially for non-cow mappings. IOW this kind of extension seems quite magical for anything that doesn't have the normal COW semantics, including for plain old read-only

[PATCH] mm: add mremap flag for preserving the old mapping

in a multi-threaded program and fragmentating memory over time is considered unacceptable. Signed-off-by: Daniel Micay danielmi...@gmail.com --- include/uapi/linux/mman.h | 1 + mm/mremap.c | 18 +++--- 2 files changed, 12 insertions(+), 7 deletions(-) diff --git

[PATCH v2] mm: add mremap flag for preserving the old mapping

of success in a multi-threaded program and fragmentating memory over time is considered unacceptable. Signed-off-by: Daniel Micay danielmi...@gmail.com --- include/uapi/linux/mman.h | 1 + mm/mremap.c | 18 +++--- 2 files changed, 12 insertions(+), 7 deletions(-) diff

Re: [PATCH v3 01/17] mm: support madvise(MADV_FREE)

> I also think that the kernel should commit to either zeroing the page > or leaving it unchanged in response to MADV_FREE (even if the decision > of which to do is made later on). I think that your patch series does > this, but only after a few of the patches are applied (the swap entry >

Re: [PATCH v3 01/17] mm: support madvise(MADV_FREE)

> And now I am thinking if we use access bit, we could implment MADV_FREE_UNDO > easily when we need it. Maybe, that's what you want. Right? Yes, but why the access bit instead of the dirty bit for that? It could always be made more strict (i.e. access bit) in the future, while going the other

Re: [PATCH v3 01/17] mm: support madvise(MADV_FREE)

On 13/11/15 01:15 AM, Minchan Kim wrote: > On Thu, Nov 12, 2015 at 12:21:30AM -0500, Daniel Micay wrote: >>> I also think that the kernel should commit to either zeroing the page >>> or leaving it unchanged in response to MADV_FREE (even if the decision >>> of whi

Re: [PATCH v3 01/17] mm: support madvise(MADV_FREE)

On 13/11/15 02:03 AM, Minchan Kim wrote: > On Fri, Nov 13, 2015 at 01:45:52AM -0500, Daniel Micay wrote: >>> And now I am thinking if we use access bit, we could implment MADV_FREE_UNDO >>> easily when we need it. Maybe, that's what you want. Right? >> >> Ye

Re: [PATCH 0/8] MADV_FREE support

e of userland people who want to use >>the syscall. >> >> A few month ago, Daniel Micay(jemalloc active contributor) requested me >> to make progress upstreaming but I was busy at that time so it took >> so long time for me to revist the code and finally, I clean i

Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE)

> Compared to MADV_DONTNEED, MADV_FREE's lazy memory free is a huge win to > reduce > page fault. But there is one issue remaining, the TLB flush. Both > MADV_DONTNEED > and MADV_FREE do TLB flush. TLB flush overhead is quite big in contemporary > multi-thread applications. In our production

Re: [PATCH 5/8] mm: move lazily freed pages to inactive list

> Even if we're wrong about the aging of those MADV_FREE pages, their > contents are invalidated; they can be discarded freely, and restoring > them is a mere GFP_ZERO allocation. All other anonymous pages have to > be written to disk, and potentially be read back. > > [ Arguably, MADV_FREE pages

Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE)

> With enough pages at once, though, munmap would be fine, too. That implies lots of page faults and zeroing though. The zeroing alone is a major performance issue. There are separate issues with munmap since it ends up resulting in a lot more virtual memory fragmentation. It would help if the

Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE)

> That's comparable to Android's pinning / unpinning API for ashmem and I > think it makes sense if it's faster. It's different than the MADV_FREE > API though, because the new allocations that are handed out won't have > the usual lazy commit which MADV_FREE provides. Pages in an allocation >

Re: [PATCH 5/8] mm: move lazily freed pages to inactive list

> From a user perspective, it doesn't depend on swap. It's just slower > without swap because it does what MADV_DONTNEED does. The current > implementation can be dropped in where MADV_DONTNEED was previously used. It just wouldn't replace existing layers of purging logic until that edge case is

Re: [PATCH 5/8] mm: move lazily freed pages to inactive list

>>> It probably makes sense to stop thinking about them as anonymous pages >>> entirely at this point when it comes to aging. They're really not. The >>> LRU lists are split to differentiate access patterns and cost of page >>> stealing (and restoring). From that angle, MADV_FREE pages really have

Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE)

> active:clean active:dirty*, sigh. signature.asc Description: OpenPGP digital signature

Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE)

> I posted a patch doing exactly iovec madvise. Doesn't support MADV_FREE yet > though, but should be easy to do it. > > http://marc.info/?l=linux-mm=144615663522661=2 I think that would be a great way to deal with this. It keeps the nice property of still being able to drop pages in allocations

Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE)

> In the common case it will be passed many pages by the allocator. There > will still be a layer of purging logic on top of MADV_FREE but it can be > much thinner than the current workarounds for MADV_DONTNEED. So the > allocator would still be coalescing dirty ranges and only purging when > the

Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE)

> Does this set the write protect bit? > > What happens on architectures without hardware dirty tracking? It's supposed to avoid needing page faults when the data is accessed again, but it can just be implemented via page faults on architectures without a way to check for access or writes.

Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE)

On 04/11/15 12:53 AM, Daniel Micay wrote: >> In the common case it will be passed many pages by the allocator. There >> will still be a layer of purging logic on top of MADV_FREE but it can be >> much thinner than the current workarounds for MADV_DONTNEED. So the >&g

Re: [PATCH v2 00/13] MADV_FREE support

On 05/12/15 06:10 AM, Pavel Machek wrote: > On Wed 2015-11-04 10:25:54, Minchan Kim wrote: >> MADV_FREE is on linux-next so long time. The reason was two, I think. >> >> 1. MADV_FREE code on reclaim path was really mess. > > Could you explain what MADV_FREE does? > > Comment in code says 'free

Re: [kernel-hardening] Re: [RFC][PATCH 0/7] Sanitization of slabs based on grsecurity/PaX

> I am not sure what the point of this patchset is. We have a similar > effect > to sanitization already in the allocators through two mechanisms: The rationale was covered earlier. Are you responding to that or did you not see it? > 1. Slab poisoning > 2. Allocation with GFP_ZERO > > I do not

Re: [kernel-hardening] [PATCH 2/2] security,perf: Allow further restriction of perf_event_open

On Fri, 2016-06-17 at 17:00 -0300, Arnaldo Carvalho de Melo wrote: > Em Fri, Jun 17, 2016 at 12:16:47PM -0400, Daniel Micay escreveu: > > On Fri, 2016-06-17 at 08:54 +0200, Peter Zijlstra wrote: > > > This Changelog is completely devoid of information. _WHY_ a

Re: [kernel-hardening] [PATCH 2/2] security,perf: Allow further restriction of perf_event_open

On Fri, 2016-06-17 at 08:54 +0200, Peter Zijlstra wrote: > On Thu, Jun 16, 2016 at 03:27:55PM -0700, Kees Cook wrote: > > Hi guys, > > > > This patch wasn't originally CCed to you (I'm fixing that now). > > Would > > you consider taking this into the perf tree?  > > No. > > > It's been in

Re: [kernel-hardening] Re: [PATCH 2/2] security,perf: Allow further restriction of perf_event_open

> As a debian user, is this a good place to complain? Because it does > get > it the way. It would be relevant to whether or not it should be set to 3 by default in the kernel without explicit configuration, but there's no proposal to do that. Debian has to pick a trade-off beyond security and a

Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled

> This feature is already implemented by two distros, and likely wanted > by others. We cannot ignore that. Date point: Arch Linux won't be enabling CONFIG_USERNS until there's a way to disable unprivileged user namespaces. The kernel maintainers are unwilling to carry long-term out-of-tree

Re: [kernel-hardening] Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies

> Then there's an unanswered question: is this patch acceptable given > that it's an ABI break?  Security fixes are sometimes an exception to > the "no ABI breaks" rule, but it's by no means an automatic exception. > > --Andy It seems this could be worked around in general. Processes can have a

Re: [kernel-hardening] Re: [PATCH] [RFC] Introduce mmap randomization

> > In the Project Zero Stagefright post > > (http://googleprojectzero.blogspot.com/2015/09/stagefrightened.html) > > , > > we see that the linear allocation of memory combined with the low > > number of bits in the initial mmap offset resulted in a much more > > predictable layout which aided the

Re: [kernel-hardening] Re: [PATCH] [RFC] Introduce mmap randomization

> > It's very hard to quantify the benefits of fine-grained > > randomization, > > ?  N = # of possible addresses.  The bigger N is, the more chances the > attacker will trip up before finding what they were looking for. If the attacker is forcing the creation of many objects with a function

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

> > So the problem I have with this is that it will completely inhibit > > development of things like JITs that self-profile to re-compile > > frequently used code. > > Or reimplement strace with sys_perf_event_open(), speeding it up > greatly > by not using ptrace (see 'perf trace', one such

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Tue, 2016-08-02 at 11:52 +0200, Peter Zijlstra wrote: > On Wed, Jul 27, 2016 at 07:45:46AM -0700, Jeff Vander Stoep wrote: > > > > When kernel.perf_event_paranoid is set to 3 (or greater), disallow > > all access to performance events by users without CAP_SYS_ADMIN. > > > > This new level of

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

> One of the strengths of linux is applications of features the authors > of > the software had not imagined.  Your proposals seem to be trying to > put > the world a tiny little box where if someone had not imagined and > preapproved a use of a feature it should not happen.   Let's please > avoid

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Thu, 2016-08-04 at 11:28 +0100, Mark Rutland wrote: > On Wed, Aug 03, 2016 at 03:36:16PM -0400, Daniel Micay wrote: > > > > There's a lot of architecture and vendor specific perf events code > > and > > lots of bleeding edge features. On Android, a lot of the perf

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Thu, 2016-08-04 at 17:10 +0100, Mark Rutland wrote: > On Thu, Aug 04, 2016 at 11:44:28AM -0400, Daniel Micay wrote: > > > > Qualcomm's drivers might be lower quality than core kernel code, but > > they're way above the baseline set by mainline kernel drivers... > >

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

> The default has no impact on the "it's too coarse and limiting" > negative property  > of this patch, which is the show-stopper aspect. Please fix that > aspect instead of  > trying to argue around it. Disabling perf events in the kernel configuration is even more limiting, and is currently the

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

Having this in Yama would also make it probable that there would be a security-centric default. It would end up wiping out unprivileged perf events access on distributions using Yama for ptrace_scope unless they make the explicit decision to disable it. Having the perf subsystem extend the

Re: [kernel-hardening] Re: [PATCH 2/2] arm: apply more __ro_after_init

On Wed, 2016-08-10 at 10:43 +0100, Russell King - ARM Linux wrote: > On Fri, Jun 03, 2016 at 11:40:24AM -0700, Kees Cook wrote: > > > > @@ -1309,16 +1309,11 @@ void __init arm_mm_memblock_reserve(void) > >   * Any other function or debugging method which may touch any > > device _will_ > >   *

Re: [kernel-hardening] Re: [PATCH v2 02/11] mm: Hardened usercopy

> I'd like it to dump stack and be fatal to the process involved, but > yeah, I guess BUG() would work. Creating an infrastructure for > handling security-related Oopses can be done separately from this > (and > I'd like to see that added, since it's a nice bit of configurable > reactivity to

Re: [kernel-hardening] Re: [PATCH v2 02/11] mm: Hardened usercopy

> This could be a BUG, but I'd rather not panic the entire kernel. It seems unlikely that it will panic without panic_on_oops and that's an explicit opt-in to taking down the system on kernel logic errors exactly like this. In grsecurity, it calls the kernel exploit handling logic (panic if root,

Re: [kernel-hardening] Re: [PATCH v2 2/3] Mark functions with the __nocapture attribute

On Tue, 2016-07-12 at 15:08 -0400, Kees Cook wrote: > On Mon, Jul 4, 2016 at 7:42 PM, Emese Revfy > wrote: > > > > The nocapture gcc attribute can be on functions only. > > The attribute takes one or more unsigned integer constants as > > parameters > > that specify the

Re: [kernel-hardening] [PATCH] [RFC] Introduce mmap randomization

On Thu, 2016-08-04 at 16:55 +, Roberts, William C wrote: > > > > -Original Message- > > From: Daniel Micay [mailto:danielmi...@gmail.com] > > Sent: Thursday, August 4, 2016 9:53 AM > > To: kernel-harden...@lists.openwall.com; ja...@lakedaemon.net; >

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

> My claim was not that the mainline code was impressively perfect, but > rather that the vendor code was worse, countering a prior claim > otherwise. Hence, reality. You're arguing with a straw man. I was responding to a comment about out-of-tree code, not generic architecture perf drivers vs.

Re: [kernel-hardening] [PATCH v4 2/2] procfs/tasks: add a simple per-task procfs hidepid= field

> This should permit Linux distributions to more comprehensively lock > down > their services, as it allows an isolated opt-in for hidepid= for > specific services. Previously hidepid= could only be set system-wide, > and then specific services had to be excluded by group membership, > essentially

Re: [PATCH] gcc-plugins: Add structleak for more stack initialization

On Mon, 2017-01-16 at 15:24 +, Mark Rutland wrote: > Hi, > > On Sat, Jan 14, 2017 at 11:03:14AM +0100, PaX Team wrote: > > On 13 Jan 2017 at 14:02, Kees Cook wrote: > > > > > +config GCC_PLUGIN_STRUCTLEAK_VERBOSE > > > + bool "Report initialized variables" > > > + depends on

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Thu, 2016-08-04 at 16:11 +0200, Peter Zijlstra wrote: > On Thu, Aug 04, 2016 at 09:45:23AM -0400, Daniel Micay wrote: > > > > Qualcomm's perf driver is out-of-tree along with most of their other > > drivers.  > > > So you're asking us to maim upstream

Re: [kernel-hardening] [PATCH] [RFC] Introduce mmap randomization

On Tue, 2016-07-26 at 11:22 -0700, william.c.robe...@intel.com wrote: > The recent get_random_long() change in get_random_range() and then the > subsequent patches Jason put out, all stemmed from my tinkering > with the concept of randomizing mmap. > > Any feedback would be greatly appreciated,

Re: [kernel-hardening] [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Wed, 2016-10-19 at 07:26 -0300, Arnaldo Carvalho de Melo wrote: > > But self profiling JITs would be useful for non-developers, on Android > (anywhere, really), and for that it would require being able to at > least, well, self profile, using sys_perf_event_open() by a normal > process,

Re: [kernel-hardening] [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Wed, 2016-10-19 at 10:41 +0100, Mark Rutland wrote: > On Mon, Oct 17, 2016 at 10:54:33AM -0400, Daniel Micay wrote: > > On Mon, 2016-10-17 at 14:44 +0100, Mark Rutland wrote: > > > It's also my understanding that for Android, perf_event_paranoid > > > is > >

Re: [kernel-hardening] [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Tue, 2016-10-18 at 13:48 -0700, Kees Cook wrote: > On Mon, Oct 17, 2016 at 6:44 AM, Mark Rutland > wrote: > > Hi, > > > > Attempt to revive discussions below... > > > > On Wed, Jul 27, 2016 at 07:45:46AM -0700, Jeff Vander Stoep wrote: > > > When

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

On Mon, 2016-10-31 at 21:45 +0100, Florian Weimer wrote: > * Jann Horn: > > > On Mon, Oct 31, 2016 at 09:04:02AM -0700, Kees Cook wrote: > > > On Mon, Oct 31, 2016 at 7:04 AM, Jann Horn wrote: > > > > On machines with sizeof(unsigned long)==8, this ensures that the > > > > more >

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

> It makes a lot of sense on x86_64 where it means the canary is still > 56 > bits. Also, you want -fstack-check for protecting again stack > overflows > rather than stack *buffer* overflow. SSP won't really help you in that > regard. Sadly, while -fstack-check now works well in GCC 6 with little

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

On Mon, 2016-10-31 at 22:10 +0100, Florian Weimer wrote: > * Daniel Micay: >  > > > It makes a lot of sense on x86_64 where it means the canary is > > > still 56 bits. Also, you want -fstack-check for protecting again > > > stack overflows rather than s

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

On Mon, 2016-10-31 at 22:22 +0100, Jann Horn wrote: > On Mon, Oct 31, 2016 at 10:10:41PM +0100, Florian Weimer wrote: > > * Daniel Micay: > > > > > > It makes a lot of sense on x86_64 where it means the canary is > > > > still 56 bits. Also, you

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

On Mon, 2016-10-31 at 22:38 +0100, Florian Weimer wrote: > * Daniel Micay: > > > -fstack-stack is supposed to handle a single guard by default, and > > that's all there is for thread stacks by default. > > Okay, then I'll really have to look at the probing offsets again.

Re: [kernel-hardening] rowhammer protection [was Re: Getting interrupt every million cache misses]

On Tue, 2016-11-01 at 07:33 +0100, Ingo Molnar wrote: > * Pavel Machek wrote: > > > I'm not going to buy broken hardware just for a test. > > Can you suggest a method to find heavily rowhammer affected hardware? > Only by  > testing it, or are there some chipset IDs ranges or

Re: [kernel-hardening] [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Mon, 2016-10-17 at 14:44 +0100, Mark Rutland wrote: > Hi, > > Attempt to revive discussions below... > > On Wed, Jul 27, 2016 at 07:45:46AM -0700, Jeff Vander Stoep wrote: > > When kernel.perf_event_paranoid is set to 3 (or greater), disallow > > all access to performance events by users

Re: [kernel-hardening] [PATCH 3/4] Make static usermode helper binaries constant

> Thanks for the explanation.  I don't think we need to worry about > merging these strings, but I'll keep it in mind. > > However, the "folklore" of the kernel was to never do: > char *foo = "bar"; > but instead do: > char foo[] = "bar"; > to save on the extra variable that the

Re: [kernel-hardening] [PATCH 3/4] Make static usermode helper binaries constant

> So for statics, I think `static const char *` wins due to allowing > merging (although it doesn't matter here). For non-statics, you end up > with extra pointer constants. Those could get removed, but Linux > doesn't > have -fvisibility=hidden and I'm not sure how clever linkers are. > Maybe >

Re: [kernel-hardening] [PATCH 3/4] Make static usermode helper binaries constant

> To follow up on this, and after staring at too many outputs of the > compiler, I think what this really should be is: > static char const critical_overtemp_path[] = > "/sbin/critical_overtemp"; > right? > > That way both the variable, and the data, end up in read-only memory > from what I

Re: [kernel-hardening] Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function

On Thu, 2016-12-15 at 15:57 +0800, Herbert Xu wrote: > Jason A. Donenfeld wrote: > > > > Siphash needs a random secret key, yes. The point is that the hash > > function remains secure so long as the secret key is kept secret. > > Other functions can't make the same guarantee,

Re: [kernel-hardening] Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

On Fri, 2016-12-16 at 11:47 -0800, Tom Herbert wrote: > > That's about 3x of jhash speed (7 nsecs). So that might closer > to a more palatable replacement for jhash. Do we lose any security > advantages with halfsiphash? Have you tested a lower round SipHash? Probably best to stick with the

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

> grsecurity and PaX are great projects. They have a lot of good ideas, > and they're put together quite nicely. The upstream kernel should > *not* do things differently from they way they are in grsecurity/PaX > just because it wants to be different. Conversely, the upstream > kernel should

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

> I probably chose the wrong name for this feature (write rarely). > That's _usually_ true, but "sensitive_write()" was getting rather > long. The things that we need to protect with this are certainly stuff > that doesn't get much writing, but some things are just plain > sensitive (like page

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

> Not too late to rename it. Scoped write? I think it makes change to s/change/sense/

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

>> Fair enough. However, placing a BUG_ON(!(read_cr0() & X86_CR0_WP)) >> somewhere sensible should make those "leaks" visible fast -- and their >> exploitation impossible, i.e. fail hard. > > The leaks surely exist and now we'll just add an exploitable BUG. That didn't seem to matter for landing

Re: [PATCH] infiniband: avoid overflow warning

On Mon, 2017-07-31 at 21:19 +0200, Arnd Bergmann wrote: > On Mon, Jul 31, 2017 at 6:17 PM, Bart Van Assche om> wrote: > > On Mon, 2017-07-31 at 18:04 +0200, Arnd Bergmann wrote: > > > On Mon, Jul 31, 2017 at 5:32 PM, Bart Van Assche > > dc.com> wrote: >

Re: [PATCHv3 2/2] extract early boot entropy from the passed cmdline

On Wed, 2017-08-16 at 23:31 -0400, Theodore Ts'o wrote: > On Wed, Aug 16, 2017 at 04:14:58PM -0700, Laura Abbott wrote: > > From: Daniel Micay <danielmi...@gmail.com> > > > > Existing Android bootloaders usually pass data useful as early > > entropy > >

Re: [kernel-hardening] [PATCHv2 2/2] extract early boot entropy from the passed cmdline

On Wed, 2017-08-16 at 21:58 -0700, Kees Cook wrote: > On Wed, Aug 16, 2017 at 9:56 PM, Nick Kralevich <n...@google.com> > wrote: > > On Wed, Aug 16, 2017 at 3:46 PM, Laura Abbott <labb...@redhat.com> > > wrote: > > > From: Daniel Micay <danielmi..

Re: [GIT PULL] Please pull NFS client changes for Linux 4.13

> The reason q_size isn't used is because it doesn't yet prevent read > overflow. The commit message mentions that among the current > limitations > along with __builtin_object_size(ptr, 1). Er rather, in strlcat, the q_size is unused after the fast path is because strnlen obtains the constant

Re: [GIT PULL] Please pull NFS client changes for Linux 4.13

On Fri, 2017-07-14 at 12:58 -0700, Linus Torvalds wrote: > On Fri, Jul 14, 2017 at 12:43 PM, Andrey Ryabinin > wrote: > > > > > yet when I look at the generated code for __ip_map_lookup, I see > > > > > >movl$32, %edx #, > > >movq%r13, %rsi

Re: [GIT PULL] Please pull NFS client changes for Linux 4.13

On Fri, 2017-07-14 at 13:50 -0700, Linus Torvalds wrote: > On Fri, Jul 14, 2017 at 1:38 PM, Daniel Micay <danielmi...@gmail.com> > wrote: > > > > If strscpy treats the count parameter as a *guarantee* of the dest > > size > > rather than a limit, > > No

Re: [GIT PULL] Please pull NFS client changes for Linux 4.13

> My initial patch used strlcpy there, because I wasn't aware of strscpy > before it was suggested: > > http://www.openwall.com/lists/kernel-hardening/2017/05/04/11 > > I was wrong to move it to strscpy. It could be switched back to > strlcpy > again unless the kernel considers the count

[PATCH] replace incorrect strscpy use in FORTIFY_SOURCE

, 1) for intra-object overflow checks since it's the maximum possible size of the specified object with no guarantee of it being that large. Reuse of the fortified functions like this currently makes the runtime error reporting less precise but that can be improved later on. Signed-off-by: Daniel

Re: [PATCH] replace incorrect strscpy use in FORTIFY_SOURCE

On Fri, 2017-07-14 at 16:51 -0700, Kees Cook wrote: > On Fri, Jul 14, 2017 at 2:28 PM, Daniel Micay <danielmi...@gmail.com> > wrote: > > Using strscpy was wrong because FORTIFY_SOURCE is passing the > > maximum > > possible size of the outermost object, but strscpy d

Re: [GIT PULL] Please pull NFS client changes for Linux 4.13

> I find "hardening" code that adds bugs to be particularly bad and > ugly, the same way that I absolutely *hate* debugging code that turns > out to make debugging impossible (we had that with the "better" stack > tracing code that caused kernel panics to kill the machine entirely > rather than

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

It was known that there are going to be bugs to work through, many of them relatively benign like the leaks of data near string constants (probably other string constants) in rodata. It makes sense to have it default to WARN with BUG / noreturn as a non-default configuration option for it, I guess

Re: [PATCH] fortify: Use WARN instead of BUG for now

I think the 'else' added in the proposed patch makes it too complicated for GCC to optimize out the __attribute__((error)) checks before they're considered to be errors. It's not needed so it's probably best to just avoid doing something like that. The runtime checks can't get false positives from

Re: [PATCH] fortify: Use WARN instead of BUG for now

It should just be renamed from fortify_panic -> fortify_error, including in arch/x86/boot/compressed/misc.c and arch/x86/boot/compressed/misc.c. It can use WARN instead of BUG by with a 'default n', !COMPILE_TEST option to use BUG again. Otherwise it needs to be patched downstream when that's

Re: [PATCH] fortify: Use WARN instead of BUG for now

> Maybe we could do two phases? One to s/BUG/WARN/ and the second to > improve the message? s/fortify_panic/fortify_overflow/ + use WARN + remove __noreturn makes sense as one commit. Still think the *option* of __noreturn + BUG should be kept there even just for measuring the size overhead.

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

> [8.134886] arch_prepare_optimized_kprobe+0xd5/0x171 > [8.134886] arch_prepare_optimized_kprobe+0xd5/0x171 Probably this: /* Copy arch-dep-instance from template */ memcpy(buf, _template_entry, TMPL_END_IDX); Not a real bug, just technically undefined because these

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

> So the fortify_string code has decided that only a single-byte (or > empty) memcpy is ok. > > And that, in turn, seems to be because we're copying from > optprobe_template_entry, which is declared as > > extern __visible kprobe_opcode_t optprobe_template_entry; > > so the fortify code

Re: [kernel-hardening] Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation

On Thu, 2017-07-06 at 10:55 -0500, Christoph Lameter wrote: > On Thu, 6 Jul 2017, Kees Cook wrote: > > > On Thu, Jul 6, 2017 at 6:43 AM, Christoph Lameter > > wrote: > > > On Wed, 5 Jul 2017, Kees Cook wrote: > > > > > > > @@ -3536,6 +3565,9 @@ static int kmem_cache_open(struct

Re: [PATCH v2] binfmt_elf: Use ELF_ET_DYN_BASE only for PIE

On Tue, 2017-06-27 at 16:49 +0200, Michal Hocko wrote: > On Wed 21-06-17 10:32:01, Kees Cook wrote: > > The ELF_ET_DYN_BASE position was originally intended to keep loaders > > away from ET_EXEC binaries. (For example, running "/lib/ld- > > linux.so.2 > > /bin/cat" might cause the subsequent load

Re: [PATCH v2] kref: Avoid null pointer dereference after WARN

On Tue, 2017-06-27 at 12:34 -0700, Kees Cook wrote: > On Tue, Jun 27, 2017 at 12:26 PM, Jason A. Donenfeld > wrote: > > On Tue, Jun 27, 2017 at 9:22 PM, Andi Kleen > > wrote: > > > Who would actually set mman_min_addr incorrectly? > > > > Historically

Re: [PATCH] infiniband: avoid overflow warning

On Mon, 2017-07-31 at 14:18 -0700, Kees Cook wrote: > On Mon, Jul 31, 2017 at 2:10 PM, Arnd Bergmann wrote: > > On Mon, Jul 31, 2017 at 10:58 PM, Kees Cook > > wrote: > > > On Mon, Jul 31, 2017 at 12:30 AM, Arnd Bergmann > > > wrote: > > > >

Re: drivers/tty/serial/8250/8250_fintek.c:364: warning: 'probe_data' is used uninitialized in this function

On Wed, 2017-08-09 at 17:32 +0200, Arnd Bergmann wrote: > On Wed, Aug 9, 2017 at 5:07 PM, kbuild test robot > wrote: > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin > > ux.git master > > head: bfa738cf3dfae2111626650f86135f93c5ff0a22 > > commit:

Re: [PATCHv3 2/2] extract early boot entropy from the passed cmdline

> I did say 'external attacker' but it could be made clearer. Er, s/say/mean to imply/ I do think it will have some local value after Android 8 which should start shipping in a few days though. I'll look into having the kernel stash some entropy in pstore soon since that seems like it could be

Re: [PATCH] kexec_file: Adjust type of kexec_purgatory

E, which did not like the memcmp() of a "0 byte" > array. > > Cc: Daniel Micay <danielmi...@gmail.com> > Signed-off-by: Kees Cook <keesc...@chromium.org> > --- > kernel/kexec_file.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > d

Re: [kernel-hardening] Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On Wed, 2017-05-17 at 17:41 +0100, Alan Cox wrote: > > If we're adjusting applications, they should be made to avoid > > TIOSCTI > > completely. This looks to me a lot like the symlink restrictions: > > yes, > > userspace should be fixed to the do the right thing, but why not > > provide support

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, 2017-05-12 at 22:06 +0100, Al Viro wrote: > On Fri, May 12, 2017 at 09:21:06PM +0100, Russell King - ARM Linux > wrote: > > On Fri, May 12, 2017 at 12:30:02PM -0700, Kees Cook wrote: > > > I'm clearly not explaining things well enough. I shouldn't say > > > "corruption", I should say

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

> overflow into adjacent allocations (fixed by VMAP_STACK). 99% fixed, but it's possible to skip over the guard page without -fstack-check enabled (plus some edge cases need to be fixed in GCC), unless VLAs were forbidden in addition to the existing large frame size warning. I'm not sure about

Re: [kernel-hardening] Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On Wed, 2017-05-10 at 21:29 +0100, Alan Cox wrote: > > In addition your change to allow it to be used by root in the guest > completely invalidates any protection you have because I can push > > "rm -rf /\n" > > as root in my namespace and exit > > The tty buffers are not flushed across the

Re: [kernel-hardening] [PATCH 23/23] mm: Allow slab_nomerge to be set at build time

On Mon, 2017-06-19 at 16:36 -0700, Kees Cook wrote: > Some hardened environments want to build kernels with slab_nomerge > already set (so that they do not depend on remembering to set the > kernel > command line option). This is desired to reduce the risk of kernel > heap > overflows being able

Re: [kernel-hardening] [PATCH] [RFC] binfmt_elf: Use ELF_ET_DYN_BASE only for PIE

On Wed, 2017-06-21 at 10:23 -0700, Kees Cook wrote: > On Wed, Jun 21, 2017 at 5:07 AM, Rik van Riel wrote: > > On Tue, 2017-06-20 at 22:58 -0700, Kees Cook wrote: > > > +/* This is the base location for PIE (ET_DYN with INTERP) loads. > > > */ > > > +#define ELF_ET_DYN_BASE

Re: [kernel-hardening] [PATCH] [RFC] binfmt_elf: Use ELF_ET_DYN_BASE only for PIE

On Wed, 2017-06-21 at 10:28 -0700, Kees Cook wrote: > On Wed, Jun 21, 2017 at 10:27 AM, Daniel Micay <danielmi...@gmail.com> > wrote: > > On Wed, 2017-06-21 at 10:23 -0700, Kees Cook wrote: > > > On Wed, Jun 21, 2017 at 5:07 AM, Rik van Riel <r...@redhat.com> >

Re: [kernel-hardening] non-x86 per-task stack canaries

On Mon, 2017-06-26 at 14:04 -0700, Kees Cook wrote: > Hi, > > The stack protector functionality on x86_64 uses %gs:0x28 (%gs is the > percpu area) for __stack_chk_guard, and all other architectures use a > global variable instead. This means we never change the stack canary > on non-x86

Re: [PATCH v3] add the option of fortified string.h functions

On Tue, 2017-05-23 at 19:12 -0700, Kees Cook wrote: > On Tue, May 23, 2017 at 3:48 PM, Andrew Morton > <a...@linux-foundation.org> wrote: > > On Mon, 22 May 2017 19:10:25 -0400 Daniel Micay <danielmicay@gmail.c > > om> wrote: > > > > > This adds

  1   2   3   4   >