From patchwork Tue Aug 20 10:30:07 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Anton Blanchard X-Patchwork-Id: 268434 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from ozlabs.org (localhost [IPv6:::1]) by ozlabs.org (Postfix) with ESMTP id 5B1DD2C02F0 for ; Tue, 20 Aug 2013 20:30:33 +1000 (EST) Received: from kryten (ppp121-45-182-214.lns20.syd7.internode.on.net [121.45.182.214]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPSA id 45E982C00F2; Tue, 20 Aug 2013 20:30:08 +1000 (EST) Date: Tue, 20 Aug 2013 20:30:07 +1000 From: Anton Blanchard To: Michael Neuling Subject: Re: [PATCH] powerpc: Never handle VSX alignment exceptions from kernel Message-ID: <20130820203007.4e0803f6@kryten> In-Reply-To: References: <20130820160516.596a85a4@kryten> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.17; x86_64-pc-linux-gnu) Mime-Version: 1.0 Cc: Paul Mackerras , linuxppc-dev , amodra@gmail.com X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.16rc2 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org Sender: "Linuxppc-dev" Hi, > Can you say what will happen when you apply this patch. ie It > produces one oops rather than megabytes of crap making it easier > to debug. Good point, updated. > Also, can you give a clue as to how you can hit this since it should > never happen in the first place. I assume it's some LE corner case... While it was found on LE, after reading the POWER7 docs I think we can hit it pretty easily on BE. All it takes is a 4 byte aligned VSX load or store. Misaligning the FPR array in the thread struct would be enough to do it and we'd end up scribbling over memory until we self destruct. Anton --- The VSX alignment handler needs to write out the existing VSX state to memory before operating on it (flush_vsx_to_thread()). If we take a VSX alignment exception in the kernel bad things will happen. It looks like we could write the kernel state out to the user process, or we could handle the kernel exception using data from the user process (depending if MSR_VSX is set or not). Worse still, if the code to read or write the VSX state causes an alignment exception, we will recurse forever. I ended up with hundreds of megabytes of kernel stack to look through as a result. Floating point and SPE code have similar issues but already include a user check. Add the same check to emulate_vsx(). With this patch any unaligned VSX loads and stores in the kernel will show up as a clear oops rather than silent corruption of kernel or userspace VSX state, or worse, corruption of a potentially unlimited amount of kernel memory. Signed-off-by: Anton Blanchard --- Index: b/arch/powerpc/kernel/align.c =================================================================== --- a/arch/powerpc/kernel/align.c +++ b/arch/powerpc/kernel/align.c @@ -651,6 +651,10 @@ static int emulate_vsx(unsigned char __u int sw = 0; int i, j; + /* userland only */ + if (unlikely(!user_mode(regs))) + return 0; + flush_vsx_to_thread(current); if (reg < 32)