Crypto 24 / 7 News

help / Atom feed * [GIT PULL] gcc-plugin updates for v4.19-rc1 @ 2018-08-13 21:43 Kees Cook 2018-08-15 16:41 ` Linus Torvalds 0 siblings, 1 reply; 11+ messages in thread From: Kees Cook @ 2018-08-13 21:43 UTC ( permalink / raw ) To: Linus Torvalds Cc: linux-kernel, Alexander Popov, Dave Hansen, Ingo Molnar, Masahiro Yamada, Thomas Gleixner, Tycho Andersen, Mark Rutland, Laura Abbott, Will Deacon Hi Linus, Please pull these gcc-plugin changes for v4.19-rc1. This has some Kconfig and Makefile cleanups from Masahiro and myself, but the bulk of this is the STACKLEAK plugin ported by Alexander Popov. As discussed in its commit logs, it provides efficient stack content poisoning at syscall exit.

This creates a defense against several classes of flaws: – uninitialized stack usage (while we continue to work on improving the compiler to do this in other ways: e.g. unconditional zero init was proposed to gcc and clang, and more plugin work has started too) – stack content exposure (by greatly reducing the lifetime of valid stack contents, exposures via either direct read bugs or unknown cache side-channels become much more difficult to exploit.

This complements the existing buddy and heap poisoning options, but provides the coverage for stacks) – stack exhaustion/guard-page skipping (while we continue to work to remove all VLAs in the kernel: of the ~115 cases found in v4.16, after the v4.19 merge window we should be down to about 13 remaining, most of them in crypto code, all of which have patches under review) The x86 hooks are included in this series (which have been reviewed by Ingo, Dave Hansen, and Thomas Gleixner), and have hopefully addressed your concerns with regard to the size of assembly changes which are now minimal. The arm64 hooks are expected to be coming through the arm64 tree during the v4.19 merge window as well (written by Laura Abbott and reviewed by Mark Rutland and Will Deacon). Thanks! -Kees The following changes since commit 7daf201d7fe8334e2d2364d4e8ed3394ec9af819: Linux 4.

18-rc2 (2018-06-24 20:54:29 +0800) are available in the Git repository at: https://git.kernel.

org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=vla/leftovers and the remaining series against crypto, for which I am waiting on further review for Herbert.

All the really odd-ball crypto cases have been handled (and are up for the merge window for v4.19), but there’s still some minor changes that Herbert is examining: https://patchwork.

kernel.org/patch/10489873/ So, we’re basically done, but the timing with the merge window wasn’t great since crypto continues to get tweaked and has taken much longer than I had expected. -Kees — Kees Cook Pixel Security ^ permalink raw reply [ flat | nested ] 11+ messages in thread * Re: [GIT PULL] gcc-plugin updates for v4.19-rc1 2018-08-15 20:56 ` Kees Cook @ 2018-08-15 21:18 ` Alexander Popov 2018-08-15 21:33 ` Linus Torvalds 0 siblings, 1 reply; 11+ messages in thread From: Alexander Popov @ 2018-08-15 21:18 UTC ( permalink / raw ) To: Kees Cook, Linus Torvalds Cc: Linux Kernel Mailing List, Dave Hansen, Ingo Molnar, Masahiro Yamada, Thomas Gleixner, Tycho Andersen, Mark Rutland, Laura Abbott, Will Deacon, Herbert Xu, linux-crypto On 15.08.2018 23:56, Kees Cook wrote: > On Wed, Aug 15, 2018 at 1:18 PM, Linus Torvalds wrote: >> I absolutely refuse to take any hardening patches at all that have >> BUG() or panic() or similar machine-killing in it. >> Okay, mental model adjusted.

🙂 It was only “strong discouraged” until now. I’ve just got the insight, how to avoid having BUG_ON() in stackleak_erase(). If ‘task_struct.lowest_stack’ is corrupted, we can erase once starting from the stack bottom and reset the ‘lowest_stack’ value. >> I care not one whit about the reason for them. In fact, if the reason >> is stated as “it makes debugging easiler”, then I fart in your general >> direction and call your mother a hamster. That is plain harassment. I ask to *stop* it! — Alexander ^ permalink raw reply [ flat | nested ] 11+ messages in thread * Re: [GIT PULL] gcc-plugin updates for v4.

19-rc1 2018-08-15 21:18 ` Alexander Popov @ 2018-08-15 21:33 ` Linus Torvalds 0 siblings, 0 replies; 11+ messages in thread From: Linus Torvalds @ 2018-08-15 21:33 UTC ( permalink / raw ) To: Alexander Popov Cc: Kees Cook, Linux Kernel Mailing List, Dave Hansen, Ingo Molnar, Masahiro Yamada, Thomas Gleixner, Tycho Andersen, Mark Rutland, Laura Abbott, Will Deacon, Herbert Xu, Linux Crypto Mailing List On Wed, Aug 15, 2018 at 2:19 PM Alexander Popov wrote: >>>> I fart in your general >>> direction and call your mother a hamster. >> That is plain harassment. I ask to *stop* it! The correct reply is “Is there someone else up there we can talk to?” just google for it if you haven’t seen the Holy Grail. (And I got the quote wrong too. I forgot about how your father smelt of elderberries) Linus ^ permalink raw reply [ flat | nested ] 11+ messages in thread * RE: [GIT PULL] gcc-plugin updates for v4.

19-rc1 2018-08-15 20:18 ` Linus Torvalds 2018-08-15 20:56 ` Kees Cook @ 2018-08-16 9:51 ` David Laight 1 sibling, 0 replies; 11+ messages in thread From: David Laight @ 2018-08-16 9:51 UTC ( permalink / raw ) To: Linus Torvalds, Kees Cook Cc: Linux Kernel Mailing List, Alexander Popov, Dave Hansen, Ingo Molnar, Masahiro Yamada, Thomas Gleixner, Tycho Andersen, Mark Rutland, Laura Abbott, Will Deacon From: Linus Torvalds > Sent: 15 August 2018 21:19 ..

. > But if people run things on real machines, then BUG() is absolutely > the last thing you EVER want to do for “debugging”. I’m not sure you want it on a live system either. Live systems are where the ‘hard’ bugs show up. I’ve just spent a couple of days pulling my hair out trying to work out how to debug a customer system that was locking up solid when running some new (and not completely testable by us) kernel code.

At 4am I suddenly realised that the distribution they are using might be enabling ‘panic_on_oops’ by default. Turning that off showed what was going wrong.

It wouldn’t be as bad if Linux implemented ‘dump to swap’. For ‘errors’ that aren’t completely fatal the system could ‘fast shutdown’ a lot of processes (maybe just refuse to schedule them) while leaving enough running for fault diagnosis.

I’m not sure how you’d decide what to allow to run though. David – Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) ^ permalink raw reply [ flat | nested ] 11+ messages in thread end of thread, back to index Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed ) — links below jump to the message on this page — 2018-08-13 21:43 [GIT PULL] gcc-plugin updates for v4.19-rc1 Kees Cook 2018-08-15 16:41 ` Linus Torvalds 2018-08-15 18:35 ` Kees Cook 2018-08-15 19:04 ` Linus Torvalds 2018-08-15 19:43 ` Alexander Popov 2018-08-15 19:45 ` Kees Cook 2018-08-15 20:18 ` Linus Torvalds 2018-08-15 20:56 ` Kees Cook 2018-08-15 21:18 ` Alexander Popov 2018-08-15 21:33 ` Linus Torvalds 2018-08-16 9:51 ` David Laight LKML Archive on lore.kernel.org Archives are clonable: git clone –mirror https://lore.

kernel.org/lkml/0 lkml/git/0.git git clone –mirror https://lore.kernel.

org/lkml/1 lkml/git/1.git git clone –mirror https://lore.kernel.

org/lkml/3 lkml/git/3.git git clone –mirror https://lore.

kernel.org/lkml/4 lkml/git/4.git git clone –mirror https://lore.kernel.

org/lkml/5 lkml/git/5.

git git clone –mirror https://lore.kernel.org/lkml/6 lkml/git/6.

git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml [email protected] linux-kernel@archiver.

kernel.org public-inbox-index lkml Newsgroup available over NNTP: nntp://nntp.lore.kernel.

org/org.kernel.vger.linux-kernel AGPL code for this site: git clone