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
| ||
|
Date: Sat, 16 Feb 2019 18:36:52 -0800 From: Andy Lutomirski <luto@...capital.net> To: Al Viro <viro@...iv.linux.org.uk> Cc: Thomas Gleixner <tglx@...utronix.de>, Jann Horn <jannh@...gle.com>, baloo@...di.net, the arch/x86 maintainers <x86@...nel.org>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, kernel list <linux-kernel@...r.kernel.org>, Pascal Bouchareine <pascal@...di.net> Subject: Re: [PATCH] x86: uaccess: fix regression in unsafe_get_user > On Feb 16, 2019, at 3:47 PM, Al Viro <viro@...iv.linux.org.uk> wrote: > >> On Sat, Feb 16, 2019 at 02:50:15PM -0800, Andy Lutomirski wrote: >> >> What is the actual problem? We’re not actually demand-faulting this data, are we? Are we just overrunning the buffer because the from_user helpers are too clever? Can we fix it for real by having the fancy helpers do *aligned* loads so that they don’t overrun the buffer? Heck, this might be faster, too. > > Unaligned _stores_ are not any cheaper, and you'd get one hell of > extra arithmetics from trying to avoid both. Check something > like e.g. memcpy() on alpha, where you really have to keep all > accesses aligned, both on load and on store side. I think we should avoid unaligned loads and do unaligned stores instead. I would general expect that unaligned stores are a bit cheaper since they don’t need to complete for the comparisons to happen. But I maintain my claim that this code should not be overrunning its input buffer into the next page, since it could have observable side effects. > > Can't we just pad the buffers a bit? Making sure that name_buf > and symlink_buf are _not_ followed by unmapped pages shouldn't > be hard. Both are allocated by kmalloc(), so... > > What am I missing here?
Powered by blists - more mailing lists