linux-kernel - Re: [RFC Patch 2/2] kexec: allow to shrink reserved memory

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: <m1r5vi9l9v.fsf@fess.ebiederm.org>
Date:	Tue, 11 Aug 2009 12:57:00 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Amerigo Wang <amwang@...hat.com>
Cc:	linux-kernel@...r.kernel.org, linux-ia64@...r.kernel.org,
	Neil Horman <nhorman@...hat.com>,
	Andi Kleen <andi@...stfloor.org>, akpm@...ux-foundation.org,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [RFC Patch 2/2] kexec: allow to shrink reserved memory

Amerigo Wang <amwang@...hat.com> writes:

> This patch implements shrinking the reserved memory for crash kernel,
> if it is more than enough.
>
> For example, if you have already reserved 128M, now you just want 100M,
> you can do:
>
> # echo $((100*1024*1024)) > /sys/kernel/kexec_crash_size

This patch looks like a reasonable start.

However once a crash kernel image is loaded we have already told that
image about the memory that is available and what you are doing here
will go and stop on the memory that is reserved but not yet used,
totally breaking the DMA protections.  AKA we know the memory is safe
from ongoing DMAs because it has lain fallow since boot up.

The only safe thing to do is to reduce the memory size before (possibly
just before) we load the crash kernel.  Which means we should only
be allowed to shrink the size when nothing is loaded, exactly the
opposite of what you have implemented.

You patch also plays with global kexec variables outside of the mutex
before calling into shrink_crash_memory.   If my memory serves just
doing mutx_lock(&kexec_mutex) on this code path should be fine.  The
mutex_trylock on the other code paths is about having non-blocking
behavior that you don't need here.

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