From: Will Deacon <will@kernel.org> To: torvalds@linux-foundation.org Cc: catalin.marinas@arm.com, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Linux ARM Kernel Mailing List <linux-arm-kernel@lists.infradead.org>, gregkh@linuxfoundation.org Subject: [GIT PULL] arm64: Another fix for 5.4 Date: Thu, 21 Nov 2019 14:44:08 +0000 [thread overview] Message-ID: <20191121144408.GA3751@willie-the-truck> (raw) Hi Linus, After I thought we were done for 5.4, we had a report this week of a nasty issue that has been shown to leak data between different user address spaces thanks to corruption of entries in the TLB. In hindsight, we should have spotted this in review when the PAN code was merged back in v4.3, but hindsight is 20/20 and I'm trying not to beat myself up too much about it despite being fairly miserable. Anyway, the fix is "obvious" but the actual failure is more more subtle, and is described in the commit message. I've included a fairly mechanical follow-up patch here as well, which moves this checking out into the C wrappers which is what we do for {get,put}_user() already and allows us to remove these bloody assembly macros entirely. The patches have passed kernelci [1] [2] [3] and CKI [4] tests over night, as well as some targetted testing [5] for this particular issue. The first patch is tagged for stable and should be applied to 4.14, 4.19 and 5.3. I have separate backports for 4.4 and 4.9, which I'll send out once this has landed in your tree (although the original patch applies cleanly, it won't build for those two trees). Thanks to Pavel Tatashin for reporting this and Mark Rutland for helping to diagnose the issue and review/test the solution. Please pull. Will [1] https://lore.kernel.org/lkml/5dd5f064.1c69fb81.5e209.59cf@mx.google.com [2] https://lore.kernel.org/lkml/5dd5faae.1c69fb81.9bfcb.6f62@mx.google.com [3] https://lore.kernel.org/lkml/5dd5fab1.1c69fb81.22bb5.755e@mx.google.com [4] https://lore.kernel.org/lkml/cki.1CBC43ABCD.523Q7TUX64@redhat.com [5] https://lore.kernel.org/lkml/CA+CK2bCX+QGMPzhjj-UmVNb1jG8Z6WNW=L0GiVsTpGrhyqb9tA@mail.gmail.com --->8 The following changes since commit 65e1f38d9a2f07d4b81f369864c105880e47bd5a: scripts/tools-support-relr.sh: un-quote variables (2019-11-13 10:52:05 +0000) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git tags/arm64-fixes for you to fetch changes up to e50be648aaa3da196d4f4ed49d1c5d4ec105fa4a: arm64: uaccess: Remove uaccess_*_not_uao asm macros (2019-11-20 18:51:54 +0000) ---------------------------------------------------------------- arm64 fix for 5.4 - Ensure PAN is re-enabled following user fault in uaccess routines ---------------------------------------------------------------- Pavel Tatashin (2): arm64: uaccess: Ensure PAN is re-enabled after unhandled uaccess fault arm64: uaccess: Remove uaccess_*_not_uao asm macros arch/arm64/include/asm/asm-uaccess.h | 17 ----------------- arch/arm64/include/asm/uaccess.h | 27 ++++++++++++++++++++++----- arch/arm64/lib/clear_user.S | 2 -- arch/arm64/lib/copy_from_user.S | 2 -- arch/arm64/lib/copy_in_user.S | 2 -- arch/arm64/lib/copy_to_user.S | 2 -- arch/arm64/lib/uaccess_flushcache.c | 6 +++++- 7 files changed, 27 insertions(+), 31 deletions(-)
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will@kernel.org> To: torvalds@linux-foundation.org Cc: catalin.marinas@arm.com, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Linux ARM Kernel Mailing List <linux-arm-kernel@lists.infradead.org>, gregkh@linuxfoundation.org Subject: [GIT PULL] arm64: Another fix for 5.4 Date: Thu, 21 Nov 2019 14:44:08 +0000 [thread overview] Message-ID: <20191121144408.GA3751@willie-the-truck> (raw) Hi Linus, After I thought we were done for 5.4, we had a report this week of a nasty issue that has been shown to leak data between different user address spaces thanks to corruption of entries in the TLB. In hindsight, we should have spotted this in review when the PAN code was merged back in v4.3, but hindsight is 20/20 and I'm trying not to beat myself up too much about it despite being fairly miserable. Anyway, the fix is "obvious" but the actual failure is more more subtle, and is described in the commit message. I've included a fairly mechanical follow-up patch here as well, which moves this checking out into the C wrappers which is what we do for {get,put}_user() already and allows us to remove these bloody assembly macros entirely. The patches have passed kernelci [1] [2] [3] and CKI [4] tests over night, as well as some targetted testing [5] for this particular issue. The first patch is tagged for stable and should be applied to 4.14, 4.19 and 5.3. I have separate backports for 4.4 and 4.9, which I'll send out once this has landed in your tree (although the original patch applies cleanly, it won't build for those two trees). Thanks to Pavel Tatashin for reporting this and Mark Rutland for helping to diagnose the issue and review/test the solution. Please pull. Will [1] https://lore.kernel.org/lkml/5dd5f064.1c69fb81.5e209.59cf@mx.google.com [2] https://lore.kernel.org/lkml/5dd5faae.1c69fb81.9bfcb.6f62@mx.google.com [3] https://lore.kernel.org/lkml/5dd5fab1.1c69fb81.22bb5.755e@mx.google.com [4] https://lore.kernel.org/lkml/cki.1CBC43ABCD.523Q7TUX64@redhat.com [5] https://lore.kernel.org/lkml/CA+CK2bCX+QGMPzhjj-UmVNb1jG8Z6WNW=L0GiVsTpGrhyqb9tA@mail.gmail.com --->8 The following changes since commit 65e1f38d9a2f07d4b81f369864c105880e47bd5a: scripts/tools-support-relr.sh: un-quote variables (2019-11-13 10:52:05 +0000) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git tags/arm64-fixes for you to fetch changes up to e50be648aaa3da196d4f4ed49d1c5d4ec105fa4a: arm64: uaccess: Remove uaccess_*_not_uao asm macros (2019-11-20 18:51:54 +0000) ---------------------------------------------------------------- arm64 fix for 5.4 - Ensure PAN is re-enabled following user fault in uaccess routines ---------------------------------------------------------------- Pavel Tatashin (2): arm64: uaccess: Ensure PAN is re-enabled after unhandled uaccess fault arm64: uaccess: Remove uaccess_*_not_uao asm macros arch/arm64/include/asm/asm-uaccess.h | 17 ----------------- arch/arm64/include/asm/uaccess.h | 27 ++++++++++++++++++++++----- arch/arm64/lib/clear_user.S | 2 -- arch/arm64/lib/copy_from_user.S | 2 -- arch/arm64/lib/copy_in_user.S | 2 -- arch/arm64/lib/copy_to_user.S | 2 -- arch/arm64/lib/uaccess_flushcache.c | 6 +++++- 7 files changed, 27 insertions(+), 31 deletions(-) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply other threads:[~2019-11-21 14:44 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-11-21 14:44 Will Deacon [this message] 2019-11-21 14:44 ` [GIT PULL] arm64: Another fix for 5.4 Will Deacon 2019-11-21 20:30 ` pr-tracker-bot 2019-11-21 20:30 ` pr-tracker-bot
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20191121144408.GA3751@willie-the-truck \ --to=will@kernel.org \ --cc=catalin.marinas@arm.com \ --cc=gregkh@linuxfoundation.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=torvalds@linux-foundation.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.