* [GIT PULL] CONFIG_EXPERIMENTAL removal for for 3.8
@ 2012-12-14 0:23 59% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2012-12-14 0:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel
[This seems to have never made it's way to lkml, so I'm resending without
the massive CC list, in case that was causing problems.]
Hi Linus,
Please pull this tree of CONFIG_EXPERIMENTAL removals for 3.8. These are
the Acked subset of patches of my larger "drop-experimental" tree that
other maintainers were not interested in carrying, so I've carried them
in my tree.
Thanks!
-Kees
The following changes since commit 29594404d7fe73cd80eaa4ee8c43dcc53970c60e:
Linux 3.7 (2012-12-10 19:30:57 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/for-linus-3.8
for you to fetch changes up to 6b81c0f59cf689e81f80d8a601b08c5316b96a1f:
tools/lguest: remove depends on CONFIG_EXPERIMENTAL (2012-12-11 16:38:26 -0800)
----------------------------------------------------------------
Initial batch of CONFIG_EXPERIMENTAL removals for 3.8.
----------------------------------------------------------------
Kees Cook (81):
make CONFIG_EXPERIMENTAL invisible and default
Documentation: remove depends on CONFIG_EXPERIMENTAL
arch/alpha: remove depends on CONFIG_EXPERIMENTAL
arch/cris/arch-v32/drivers: remove depends on CONFIG_EXPERIMENTAL
arch/ia64/kvm: remove depends on CONFIG_EXPERIMENTAL
arch/ia64: remove depends on CONFIG_EXPERIMENTAL
arch/ia64/xen: remove depends on CONFIG_EXPERIMENTAL
arch/powerpc/platforms/ps3: remove depends on CONFIG_EXPERIMENTAL
arch/s390: remove depends on CONFIG_EXPERIMENTAL
arch/s390/kvm: remove depends on CONFIG_EXPERIMENTAL
arch/um: remove depends on CONFIG_EXPERIMENTAL
arch/x86: remove depends on CONFIG_EXPERIMENTAL
arch/x86/um: remove depends on CONFIG_EXPERIMENTAL
crypto: remove depends on CONFIG_EXPERIMENTAL
drivers/cpufreq: remove depends on CONFIG_EXPERIMENTAL
drivers/gpu/drm/udl: remove depends on CONFIG_EXPERIMENTAL
drivers/i2c/muxes: remove depends on CONFIG_EXPERIMENTAL
drivers/ide: remove depends on CONFIG_EXPERIMENTAL
drivers/lguest: remove depends on CONFIG_EXPERIMENTAL
drivers/mmc/core: remove depends on CONFIG_EXPERIMENTAL
drivers/mmc/host: remove depends on CONFIG_EXPERIMENTAL
drivers/media: remove depends on CONFIG_EXPERIMENTAL
drivers/media/video/cx25821: remove depends on CONFIG_EXPERIMENTAL
drivers/media/video/pvrusb2: remove depends on CONFIG_EXPERIMENTAL
drivers/media/video/s5p-fimc: remove depends on CONFIG_EXPERIMENTAL
drivers/media/video/s5p-tv: remove depends on CONFIG_EXPERIMENTAL
drivers/mtd: remove depends on CONFIG_EXPERIMENTAL
drivers/mtd/chips: remove depends on CONFIG_EXPERIMENTAL
drivers/mtd/devices: remove depends on CONFIG_EXPERIMENTAL
drivers/mtd/nand: remove depends on CONFIG_EXPERIMENTAL
drivers/net: remove depends on CONFIG_EXPERIMENTAL
drivers/net/ethernet/8390: remove depends on CONFIG_EXPERIMENTAL
drivers/net/ethernet/atheros: remove depends on CONFIG_EXPERIMENTAL
drivers/net/ethernet/dec/tulip: remove depends on CONFIG_EXPERIMENTAL
drivers/net/ethernet/i825xx: remove depends on CONFIG_EXPERIMENTAL
drivers/net/ethernet/intel: remove depends on CONFIG_EXPERIMENTAL
drivers/net/ethernet/natsemi: remove depends on CONFIG_EXPERIMENTAL
drivers/net/ethernet/packetengines: remove depends on CONFIG_EXPERIMENTAL
drivers/net/ethernet/realtek: remove depends on CONFIG_EXPERIMENTAL
drivers/net/ethernet/silan: remove depends on CONFIG_EXPERIMENTAL
drivers/net/ethernet/ti: remove depends on CONFIG_EXPERIMENTAL
drivers/net/team: remove depends on CONFIG_EXPERIMENTAL
drivers/net/wan: remove depends on CONFIG_EXPERIMENTAL
drivers/net/usb: remove depends on CONFIG_EXPERIMENTAL
drivers/pcmcia: remove depends on CONFIG_EXPERIMENTAL
drivers/ptp: remove depends on CONFIG_EXPERIMENTAL
drivers/rpmsg: remove depends on CONFIG_EXPERIMENTAL
drivers/sbus/char: remove depends on CONFIG_EXPERIMENTAL
drivers/virtio: remove depends on CONFIG_EXPERIMENTAL
fs/ceph: remove depends on CONFIG_EXPERIMENTAL
fs/ecryptfs: remove depends on CONFIG_EXPERIMENTAL
fs/nilfs2: remove depends on CONFIG_EXPERIMENTAL
fs/xfs: remove depends on CONFIG_EXPERIMENTAL
init: remove depends on CONFIG_EXPERIMENTAL
kernel/gcov: remove depends on CONFIG_EXPERIMENTAL
net: remove depends on CONFIG_EXPERIMENTAL
net/9p: remove depends on CONFIG_EXPERIMENTAL
net/ceph: remove depends on CONFIG_EXPERIMENTAL
net/dccp/ccids: remove depends on CONFIG_EXPERIMENTAL
net/dccp: remove depends on CONFIG_EXPERIMENTAL
net/decnet/netfilter: remove depends on CONFIG_EXPERIMENTAL
net/decnet: remove depends on CONFIG_EXPERIMENTAL
net/dsa: remove depends on CONFIG_EXPERIMENTAL
net/ieee802154: remove depends on CONFIG_EXPERIMENTAL
net/ipv4/netfilter: remove depends on CONFIG_EXPERIMENTAL
net/ipv4: remove depends on CONFIG_EXPERIMENTAL
net/ipv6: remove depends on CONFIG_EXPERIMENTAL
net/l2tp: remove depends on CONFIG_EXPERIMENTAL
net/lapb: remove depends on CONFIG_EXPERIMENTAL
net/mac80211: remove depends on CONFIG_EXPERIMENTAL
net/mac802154: remove depends on CONFIG_EXPERIMENTAL
net/netfilter: remove depends on CONFIG_EXPERIMENTAL
net/rds: remove depends on CONFIG_EXPERIMENTAL
net/rxrpc: remove depends on CONFIG_EXPERIMENTAL
net/sctp: remove depends on CONFIG_EXPERIMENTAL
net/sunrpc: remove depends on CONFIG_EXPERIMENTAL
net/tipc: remove depends on CONFIG_EXPERIMENTAL
net/wanrouter: remove depends on CONFIG_EXPERIMENTAL
net/x25: remove depends on CONFIG_EXPERIMENTAL
net/xfrm: remove depends on CONFIG_EXPERIMENTAL
tools/lguest: remove depends on CONFIG_EXPERIMENTAL
Documentation/CodingStyle | 10 +-----
Documentation/DocBook/kernel-hacking.tmpl | 7 ----
Documentation/DocBook/kgdb.tmpl | 6 ++--
Documentation/intel_txt.txt | 2 +-
Documentation/zh_CN/CodingStyle | 7 ----
arch/alpha/Kconfig | 3 +-
arch/cris/arch-v32/drivers/Kconfig | 4 +--
arch/ia64/Kconfig | 8 ++---
arch/ia64/kvm/Kconfig | 2 +-
arch/ia64/xen/Kconfig | 2 +-
arch/powerpc/platforms/ps3/Kconfig | 2 +-
arch/s390/Kconfig | 4 +--
arch/s390/kvm/Kconfig | 2 +-
arch/um/Kconfig.net | 2 +-
arch/um/Kconfig.um | 8 ++---
arch/x86/Kconfig | 22 ++++++------
arch/x86/um/Kconfig | 3 +-
crypto/Kconfig | 15 +++-----
drivers/cpufreq/Kconfig.arm | 4 +--
drivers/cpufreq/Kconfig.x86 | 6 ++--
drivers/gpu/drm/udl/Kconfig | 2 +-
drivers/i2c/muxes/Kconfig | 2 --
drivers/ide/Kconfig | 8 ++---
drivers/lguest/Kconfig | 2 +-
drivers/media/Kconfig | 7 ++--
drivers/media/pci/cx25821/Kconfig | 2 +-
drivers/media/platform/s5p-fimc/Kconfig | 1 -
drivers/media/platform/s5p-tv/Kconfig | 3 +-
drivers/media/usb/pvrusb2/Kconfig | 8 ++---
drivers/mmc/core/Kconfig | 3 +-
drivers/mmc/host/Kconfig | 20 +++++------
drivers/mtd/Kconfig | 2 +-
drivers/mtd/chips/Kconfig | 2 +-
drivers/mtd/devices/Kconfig | 4 +--
drivers/mtd/nand/Kconfig | 7 ++--
drivers/net/Kconfig | 9 +++--
drivers/net/ethernet/8390/Kconfig | 21 +++++------
drivers/net/ethernet/atheros/Kconfig | 8 ++---
drivers/net/ethernet/dec/tulip/Kconfig | 4 +--
drivers/net/ethernet/i825xx/Kconfig | 12 +++----
drivers/net/ethernet/intel/Kconfig | 9 ++---
drivers/net/ethernet/natsemi/Kconfig | 3 --
drivers/net/ethernet/packetengines/Kconfig | 4 +--
drivers/net/ethernet/realtek/Kconfig | 4 +--
drivers/net/ethernet/silan/Kconfig | 6 ++--
drivers/net/ethernet/ti/Kconfig | 4 +--
drivers/net/team/Kconfig | 3 +-
drivers/net/usb/Kconfig | 16 ++++-----
drivers/net/wan/Kconfig | 8 ++---
drivers/pcmcia/Kconfig | 4 +--
drivers/ptp/Kconfig | 1 -
drivers/rpmsg/Kconfig | 3 +-
drivers/sbus/char/Kconfig | 7 ++--
drivers/virtio/Kconfig | 8 ++---
fs/ceph/Kconfig | 4 +--
fs/ecryptfs/Kconfig | 4 +--
fs/nilfs2/Kconfig | 3 +-
fs/xfs/Kconfig | 4 +--
init/Kconfig | 54 +++++++---------------------
kernel/gcov/Kconfig | 2 +-
net/9p/Kconfig | 2 +-
net/Kconfig | 5 ++-
net/ceph/Kconfig | 4 +--
net/dccp/Kconfig | 4 +--
net/dccp/ccids/Kconfig | 5 ++-
net/decnet/Kconfig | 4 +--
net/decnet/netfilter/Kconfig | 2 +-
net/dsa/Kconfig | 2 +-
net/ieee802154/Kconfig | 3 +-
net/ipv4/Kconfig | 11 +-----
net/ipv4/netfilter/Kconfig | 4 +--
net/ipv6/Kconfig | 24 ++++++-------
net/l2tp/Kconfig | 4 +--
net/lapb/Kconfig | 3 +-
net/mac80211/Kconfig | 2 +-
net/mac802154/Kconfig | 2 +-
net/netfilter/Kconfig | 24 +++++--------
net/rds/Kconfig | 4 +--
net/rxrpc/Kconfig | 2 +-
net/sctp/Kconfig | 4 +--
net/sunrpc/Kconfig | 2 +-
net/tipc/Kconfig | 4 +--
net/wanrouter/Kconfig | 1 -
net/x25/Kconfig | 3 +-
net/xfrm/Kconfig | 16 ++++-----
tools/lguest/lguest.txt | 8 ++---
86 files changed, 209 insertions(+), 337 deletions(-)
--
Kees Cook
Chrome OS Security
^ permalink raw reply [relevance 59%]
* [RESEND][GIT PULL] CONFIG_EXPERIMENTAL removal for 3.8
@ 2012-12-19 18:42 67% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2012-12-19 18:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Andrew Morton, Greg Kroah-Hartman, Kees Cook
Hi Linus,
Please pull this tree of CONFIG_EXPERIMENTAL removals for 3.8. These
are the Acked subset of patches of my larger "drop-experimental" tree
that other maintainers asked me to carry for them in linux-next.
There are some conflicts that have cropped up during the merge window,
but they're all pretty trivial: take what ever is most recent and delete
"EXPERIMENTAL". :)
Thanks!
-Kees
The following changes since commit 29594404d7fe73cd80eaa4ee8c43dcc53970c60e:
Linux 3.7 (2012-12-10 19:30:57 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/for-linus-3.8
for you to fetch changes up to 6b81c0f59cf689e81f80d8a601b08c5316b96a1f:
tools/lguest: remove depends on CONFIG_EXPERIMENTAL (2012-12-11 16:38:26 -0800)
----------------------------------------------------------------
Initial batch of CONFIG_EXPERIMENTAL removals for 3.8.
----------------------------------------------------------------
Kees Cook (81):
make CONFIG_EXPERIMENTAL invisible and default
Documentation: remove depends on CONFIG_EXPERIMENTAL
arch/alpha: remove depends on CONFIG_EXPERIMENTAL
arch/cris/arch-v32/drivers: remove depends on CONFIG_EXPERIMENTAL
arch/ia64/kvm: remove depends on CONFIG_EXPERIMENTAL
arch/ia64: remove depends on CONFIG_EXPERIMENTAL
arch/ia64/xen: remove depends on CONFIG_EXPERIMENTAL
arch/powerpc/platforms/ps3: remove depends on CONFIG_EXPERIMENTAL
arch/s390: remove depends on CONFIG_EXPERIMENTAL
arch/s390/kvm: remove depends on CONFIG_EXPERIMENTAL
arch/um: remove depends on CONFIG_EXPERIMENTAL
arch/x86: remove depends on CONFIG_EXPERIMENTAL
arch/x86/um: remove depends on CONFIG_EXPERIMENTAL
crypto: remove depends on CONFIG_EXPERIMENTAL
drivers/cpufreq: remove depends on CONFIG_EXPERIMENTAL
drivers/gpu/drm/udl: remove depends on CONFIG_EXPERIMENTAL
drivers/i2c/muxes: remove depends on CONFIG_EXPERIMENTAL
drivers/ide: remove depends on CONFIG_EXPERIMENTAL
drivers/lguest: remove depends on CONFIG_EXPERIMENTAL
drivers/mmc/core: remove depends on CONFIG_EXPERIMENTAL
drivers/mmc/host: remove depends on CONFIG_EXPERIMENTAL
drivers/media: remove depends on CONFIG_EXPERIMENTAL
drivers/media/video/cx25821: remove depends on CONFIG_EXPERIMENTAL
drivers/media/video/pvrusb2: remove depends on CONFIG_EXPERIMENTAL
drivers/media/video/s5p-fimc: remove depends on CONFIG_EXPERIMENTAL
drivers/media/video/s5p-tv: remove depends on CONFIG_EXPERIMENTAL
drivers/mtd: remove depends on CONFIG_EXPERIMENTAL
drivers/mtd/chips: remove depends on CONFIG_EXPERIMENTAL
drivers/mtd/devices: remove depends on CONFIG_EXPERIMENTAL
drivers/mtd/nand: remove depends on CONFIG_EXPERIMENTAL
drivers/net: remove depends on CONFIG_EXPERIMENTAL
drivers/net/ethernet/8390: remove depends on CONFIG_EXPERIMENTAL
drivers/net/ethernet/atheros: remove depends on CONFIG_EXPERIMENTAL
drivers/net/ethernet/dec/tulip: remove depends on CONFIG_EXPERIMENTAL
drivers/net/ethernet/i825xx: remove depends on CONFIG_EXPERIMENTAL
drivers/net/ethernet/intel: remove depends on CONFIG_EXPERIMENTAL
drivers/net/ethernet/natsemi: remove depends on CONFIG_EXPERIMENTAL
drivers/net/ethernet/packetengines: remove depends on CONFIG_EXPERIMENTAL
drivers/net/ethernet/realtek: remove depends on CONFIG_EXPERIMENTAL
drivers/net/ethernet/silan: remove depends on CONFIG_EXPERIMENTAL
drivers/net/ethernet/ti: remove depends on CONFIG_EXPERIMENTAL
drivers/net/team: remove depends on CONFIG_EXPERIMENTAL
drivers/net/wan: remove depends on CONFIG_EXPERIMENTAL
drivers/net/usb: remove depends on CONFIG_EXPERIMENTAL
drivers/pcmcia: remove depends on CONFIG_EXPERIMENTAL
drivers/ptp: remove depends on CONFIG_EXPERIMENTAL
drivers/rpmsg: remove depends on CONFIG_EXPERIMENTAL
drivers/sbus/char: remove depends on CONFIG_EXPERIMENTAL
drivers/virtio: remove depends on CONFIG_EXPERIMENTAL
fs/ceph: remove depends on CONFIG_EXPERIMENTAL
fs/ecryptfs: remove depends on CONFIG_EXPERIMENTAL
fs/nilfs2: remove depends on CONFIG_EXPERIMENTAL
fs/xfs: remove depends on CONFIG_EXPERIMENTAL
init: remove depends on CONFIG_EXPERIMENTAL
kernel/gcov: remove depends on CONFIG_EXPERIMENTAL
net: remove depends on CONFIG_EXPERIMENTAL
net/9p: remove depends on CONFIG_EXPERIMENTAL
net/ceph: remove depends on CONFIG_EXPERIMENTAL
net/dccp/ccids: remove depends on CONFIG_EXPERIMENTAL
net/dccp: remove depends on CONFIG_EXPERIMENTAL
net/decnet/netfilter: remove depends on CONFIG_EXPERIMENTAL
net/decnet: remove depends on CONFIG_EXPERIMENTAL
net/dsa: remove depends on CONFIG_EXPERIMENTAL
net/ieee802154: remove depends on CONFIG_EXPERIMENTAL
net/ipv4/netfilter: remove depends on CONFIG_EXPERIMENTAL
net/ipv4: remove depends on CONFIG_EXPERIMENTAL
net/ipv6: remove depends on CONFIG_EXPERIMENTAL
net/l2tp: remove depends on CONFIG_EXPERIMENTAL
net/lapb: remove depends on CONFIG_EXPERIMENTAL
net/mac80211: remove depends on CONFIG_EXPERIMENTAL
net/mac802154: remove depends on CONFIG_EXPERIMENTAL
net/netfilter: remove depends on CONFIG_EXPERIMENTAL
net/rds: remove depends on CONFIG_EXPERIMENTAL
net/rxrpc: remove depends on CONFIG_EXPERIMENTAL
net/sctp: remove depends on CONFIG_EXPERIMENTAL
net/sunrpc: remove depends on CONFIG_EXPERIMENTAL
net/tipc: remove depends on CONFIG_EXPERIMENTAL
net/wanrouter: remove depends on CONFIG_EXPERIMENTAL
net/x25: remove depends on CONFIG_EXPERIMENTAL
net/xfrm: remove depends on CONFIG_EXPERIMENTAL
tools/lguest: remove depends on CONFIG_EXPERIMENTAL
Documentation/CodingStyle | 10 +-----
Documentation/DocBook/kernel-hacking.tmpl | 7 ----
Documentation/DocBook/kgdb.tmpl | 6 ++--
Documentation/intel_txt.txt | 2 +-
Documentation/zh_CN/CodingStyle | 7 ----
arch/alpha/Kconfig | 3 +-
arch/cris/arch-v32/drivers/Kconfig | 4 +--
arch/ia64/Kconfig | 8 ++---
arch/ia64/kvm/Kconfig | 2 +-
arch/ia64/xen/Kconfig | 2 +-
arch/powerpc/platforms/ps3/Kconfig | 2 +-
arch/s390/Kconfig | 4 +--
arch/s390/kvm/Kconfig | 2 +-
arch/um/Kconfig.net | 2 +-
arch/um/Kconfig.um | 8 ++---
arch/x86/Kconfig | 22 ++++++------
arch/x86/um/Kconfig | 3 +-
crypto/Kconfig | 15 +++-----
drivers/cpufreq/Kconfig.arm | 4 +--
drivers/cpufreq/Kconfig.x86 | 6 ++--
drivers/gpu/drm/udl/Kconfig | 2 +-
drivers/i2c/muxes/Kconfig | 2 --
drivers/ide/Kconfig | 8 ++---
drivers/lguest/Kconfig | 2 +-
drivers/media/Kconfig | 7 ++--
drivers/media/pci/cx25821/Kconfig | 2 +-
drivers/media/platform/s5p-fimc/Kconfig | 1 -
drivers/media/platform/s5p-tv/Kconfig | 3 +-
drivers/media/usb/pvrusb2/Kconfig | 8 ++---
drivers/mmc/core/Kconfig | 3 +-
drivers/mmc/host/Kconfig | 20 +++++------
drivers/mtd/Kconfig | 2 +-
drivers/mtd/chips/Kconfig | 2 +-
drivers/mtd/devices/Kconfig | 4 +--
drivers/mtd/nand/Kconfig | 7 ++--
drivers/net/Kconfig | 9 +++--
drivers/net/ethernet/8390/Kconfig | 21 +++++------
drivers/net/ethernet/atheros/Kconfig | 8 ++---
drivers/net/ethernet/dec/tulip/Kconfig | 4 +--
drivers/net/ethernet/i825xx/Kconfig | 12 +++----
drivers/net/ethernet/intel/Kconfig | 9 ++---
drivers/net/ethernet/natsemi/Kconfig | 3 --
drivers/net/ethernet/packetengines/Kconfig | 4 +--
drivers/net/ethernet/realtek/Kconfig | 4 +--
drivers/net/ethernet/silan/Kconfig | 6 ++--
drivers/net/ethernet/ti/Kconfig | 4 +--
drivers/net/team/Kconfig | 3 +-
drivers/net/usb/Kconfig | 16 ++++-----
drivers/net/wan/Kconfig | 8 ++---
drivers/pcmcia/Kconfig | 4 +--
drivers/ptp/Kconfig | 1 -
drivers/rpmsg/Kconfig | 3 +-
drivers/sbus/char/Kconfig | 7 ++--
drivers/virtio/Kconfig | 8 ++---
fs/ceph/Kconfig | 4 +--
fs/ecryptfs/Kconfig | 4 +--
fs/nilfs2/Kconfig | 3 +-
fs/xfs/Kconfig | 4 +--
init/Kconfig | 54 +++++++---------------------
kernel/gcov/Kconfig | 2 +-
net/9p/Kconfig | 2 +-
net/Kconfig | 5 ++-
net/ceph/Kconfig | 4 +--
net/dccp/Kconfig | 4 +--
net/dccp/ccids/Kconfig | 5 ++-
net/decnet/Kconfig | 4 +--
net/decnet/netfilter/Kconfig | 2 +-
net/dsa/Kconfig | 2 +-
net/ieee802154/Kconfig | 3 +-
net/ipv4/Kconfig | 11 +-----
net/ipv4/netfilter/Kconfig | 4 +--
net/ipv6/Kconfig | 24 ++++++-------
net/l2tp/Kconfig | 4 +--
net/lapb/Kconfig | 3 +-
net/mac80211/Kconfig | 2 +-
net/mac802154/Kconfig | 2 +-
net/netfilter/Kconfig | 24 +++++--------
net/rds/Kconfig | 4 +--
net/rxrpc/Kconfig | 2 +-
net/sctp/Kconfig | 4 +--
net/sunrpc/Kconfig | 2 +-
net/tipc/Kconfig | 4 +--
net/wanrouter/Kconfig | 1 -
net/x25/Kconfig | 3 +-
net/xfrm/Kconfig | 16 ++++-----
tools/lguest/lguest.txt | 8 ++---
86 files changed, 209 insertions(+), 337 deletions(-)
--
Kees Cook
Chrome OS Security
^ permalink raw reply [relevance 67%]
* Re: [GIT pull] x86 updates for 3.11
@ 2013-07-15 21:10 92% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2013-07-15 21:10 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: H. Peter Anvin, Linus Torvalds, Andrew Morton, LKML
On Mon, Jul 15, 2013 at 1:45 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Sat, 13 Jul 2013, H. Peter Anvin wrote:
>
>> Fail on me. I got rushed and sloppy. I really need to automate looking
>> for warnings pre-commit and not rely on Fengguang's robot.
>
> /me too. I took it for granted that this was tested by Ingos machinery
> w/o noticing that it went in just when Ingo left for a long
> weekend. So in my own rush to get out for the weekend I left out my
> usual smoke tests on that branch. Sorry about that.
I apologize; I was rushed as well. I've changed my build and test
procedures to more loudly present warnings.
-Kees
--
Kees Cook
Chrome OS Security
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] x86/kaslr for v3.14
@ 2014-01-21 5:18 92% ` Kees Cook
1 sibling, 0 replies; 200+ results
From: Kees Cook @ 2014-01-21 5:18 UTC (permalink / raw)
To: Linus Torvalds
Cc: H. Peter Anvin, Cong Ding, H. Peter Anvin, Ingo Molnar,
Ingo Molnar, Linux Kernel Mailing List, Mathias Krause,
Michael Davidson, Thomas Gleixner, Wei Yongjun
On Mon, Jan 20, 2014 at 2:54 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> So I pulled this, but one question:
>
> On Mon, Jan 20, 2014 at 8:47 AM, H. Peter Anvin <hpa@zytor.com> wrote:
>> +config RANDOMIZE_BASE
>> + bool "Randomize the address of the kernel image"
>> + depends on RELOCATABLE
>> + depends on !HIBERNATION
>
> How fundamental is that "!HIBERNATION" issue? Right now that
> anti-dependency on hibernation support will mean that no distro kernel
> will actually use the kernel address space randomization. Which
> long-term is a problem.
>
> I'm not sure HIBERNATION is really getting all that much use, but I
> suspect distros would still want to support it.
>
> Is it just a temporary "I wasn't able to make it work, need to get
> some PM people involved", or is it something really fundamental?
Right, this is a "need to get PM people involved" situation. When
kASLR was being designed, hibernation learning about the kernel base
looked like a separable problem, and given the very long list of
requirements for making it work at all, I carved this out as "future
work".
As for perf, it's similar -- it's another entirely solvable problem,
but perf needs to be untaught some of its assumptions.
We've had a static kernel base forever, so I'm expecting some bumps in
the road here. I'm hopeful none of it will be too painful, though.
-Kees
--
Kees Cook
Chrome OS Security
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] x86/kaslr for v3.14
@ 2014-01-21 18:37 92% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2014-01-21 18:37 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Peter Zijlstra, Linus Torvalds, Arnaldo Carvalho de Melo,
Cong Ding, H. Peter Anvin, Ingo Molnar, Ingo Molnar,
Linux Kernel Mailing List, Mathias Krause, Michael Davidson,
Thomas Gleixner, Wei Yongjun
On Tue, Jan 21, 2014 at 6:20 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 01/21/2014 01:00 AM, Peter Zijlstra wrote:
>>>
>>> So this is presumably something that needs to be fixed in perf?
>>
>> Where do we learn about the offset from userspace?
>
> Now this is tricky... if this offset is too easy to get it completely
> defeats kASLR. On the other hand, I presume that if we are exporting
> /proc/kcore we're not secure anyway. Kees, I assume that in "secure"
> mode perf annotations simply wouldn't work anyway?
The goal scope of the kernel base address randomization is to keep it
secret from non-root users, confined processes, and/or remote systems.
For local secrecy, if you're running with kaslr and you haven't set
kptr_restrict, dmesg_restrict, and perf_event_paranoid, that's a
problem since you're likely leaking things trivially through
/proc/kallsyms, dmesg, and/or perf.
-Kees
--
Kees Cook
Chrome OS Security
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] x86/kaslr for v3.14
@ 2014-01-27 17:05 87% ` Kees Cook
1 sibling, 1 reply; 200+ results
From: Kees Cook @ 2014-01-27 17:05 UTC (permalink / raw)
To: Richard Weinberger
Cc: H. Peter Anvin, H. Peter Anvin, Linus Torvalds, Cong Ding,
Ingo Molnar, Ingo Molnar, Linux Kernel Mailing List,
Mathias Krause, Michael Davidson, Thomas Gleixner, Wei Yongjun
On Sun, Jan 26, 2014 at 10:49 PM, Richard Weinberger
<richard.weinberger@gmail.com> wrote:
> On Mon, Jan 27, 2014 at 6:33 AM, H. Peter Anvin <hpa@linux.intel.com> wrote:
>> On 01/26/2014 02:16 AM, Richard Weinberger wrote:
>>>
>>> Currently we print the kernel offset only upon a panic() using the
>>> panic notifier list.
>>> This way it does not show up if the kernel hits a BUG() in process
>>> context or something less critical.
>>> Wouldn't make more sense to report the offset in every dump_stack() or
>>> show_regs() call?
>>
>> No, because that information is available to user space unless we panic.
>
> Didn't you mean non-root?
> I thought one has to set dmesg_restrict anyways if kASLR is used.
>
> And isn't the offset available to perf too?
> Of course only for root, but still user space.
Setting dmesg_restrict is done mostly in an effort to try to lock down
access to dmesg since it'll likely contain enough clues to help an
attacker. System owners need to avoid dmesg getting sprayed into
/var/log world-readable, or available via privileged debugging
daemons, etc. Since keeping dmesg secret from non-root users is going
to be error-prone, I had a goal of keeping the offset out of dmesg
while the system is still running -- hence doing it only at panic
time.
Finding the offset as the (unconfined) root user is extremely easy, so
I personally see no reason to hide it from root (and it would be very
irritating for things like perf, too). I view kASLR as a tool for
statistical defense against confined processes or remote attacks.
I would argue that decoding a non-panic oops on a running system is
entirely possible as-is, since the offset can be found from
/proc/kallsyms as root. It was the dead system that needed the offset
exported: via text in the panic, or via an ELF note in a core.
-Kees
--
Kees Cook
Chrome OS Security
^ permalink raw reply [relevance 87%]
* Re: [GIT PULL] x86/kaslr for v3.14
@ 2014-01-27 17:24 92% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2014-01-27 17:24 UTC (permalink / raw)
To: Richard Weinberger
Cc: H. Peter Anvin, H. Peter Anvin, Linus Torvalds, Cong Ding,
Ingo Molnar, Ingo Molnar, Linux Kernel Mailing List,
Mathias Krause, Michael Davidson, Thomas Gleixner, Wei Yongjun
On Mon, Jan 27, 2014 at 9:20 AM, Richard Weinberger <richard@nod.at> wrote:
> Am 27.01.2014 18:05, schrieb Kees Cook:
>> I would argue that decoding a non-panic oops on a running system is
>> entirely possible as-is, since the offset can be found from
>> /proc/kallsyms as root. It was the dead system that needed the offset
>> exported: via text in the panic, or via an ELF note in a core.
>
> The problem is that you have to pickup information from two sources.
> As a kernel developer users/customers often show you a backtrace (oops or panic)
> and want you do find the problem.
> They barley manage it copy&paste the topmost full trace from dmesg or /var/log/messages.
> If I have to ask them a bit later to tell me the offset from /proc/kallsyms or something else
> I'm lost. Mostly because they have already rebooted the box...
As long as I can turn it off, I'd be happy. :)
/proc/sys/kernel/kaslr_in_oops or something?
-Kees
--
Kees Cook
Chrome OS Security
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] x86/kaslr for v3.14
@ 2014-01-31 16:57 92% ` Kees Cook
0 siblings, 1 reply; 200+ results
From: Kees Cook @ 2014-01-31 16:57 UTC (permalink / raw)
To: Vivek Goyal
Cc: H. Peter Anvin, Richard Weinberger, H. Peter Anvin,
Linus Torvalds, Cong Ding, Ingo Molnar, Ingo Molnar,
Linux Kernel Mailing List, Mathias Krause, Michael Davidson,
Thomas Gleixner, Wei Yongjun
On Thu, Jan 30, 2014 at 2:07 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> On Sun, Jan 26, 2014 at 10:51:06PM -0800, H. Peter Anvin wrote:
>> On 01/26/2014 10:49 PM, Richard Weinberger wrote:
>> >>
>> >> No, because that information is available to user space unless we panic.
>> >
>> > Didn't you mean non-root?
>> > I thought one has to set dmesg_restrict anyways if kASLR is used.
>> >
>> > And isn't the offset available to perf too?
>> > Of course only for root, but still user space.
>> >
>>
>> For certain system security levels one want to protect even from a rogue
>> root. In those cases, leaking that information via dmesg and perf isn't
>> going to work, either.
>>
>> With lower security settings, by all means...
>
> I am wondering if kdump functionality is impacted with this change.
>
> Kexec tools prepares ELF headers for kernel memory ranges and for the
> range where kernel text is mapped. So it needs to know virtual address
> of the region where kernel is mapped (obtained by /proc/kcore) and
> it gets the physical address where kernel is loaded from /proc/iomem.
>
> So with this change are we planning to hide kernel text virtual address and
> physical address information information from root in /proc/kcore and
> /proc/iomem in anyway?
I have no intention of that. Mentioned earlier in the thread, hiding
it from root will be pretty ugly/hard/pointless:
https://lkml.org/lkml/2014/1/27/287
I would like to just keep the offset out of dmesg.
-Kees
--
Kees Cook
Chrome OS Security
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] x86/kaslr for v3.14
@ 2014-02-07 19:44 92% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2014-02-07 19:44 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Vivek Goyal, H. Peter Anvin, Richard Weinberger, Linus Torvalds,
Cong Ding, Ingo Molnar, Ingo Molnar, Linux Kernel Mailing List,
Mathias Krause, Michael Davidson, Thomas Gleixner, Wei Yongjun,
Dave Young, Kexec Mailing List
On Fri, Feb 7, 2014 at 11:07 AM, H. Peter Anvin <hpa@linux.intel.com> wrote:
> On 02/07/2014 06:49 AM, Vivek Goyal wrote:
>>
>> As a workaround, Dave is currently using "nokaslr" command line parameter
>> for second kernel. He is still facing issues where makedumpfile segment
>> faults. He is looking into it further.
>>
>
> Now, let's state this: kaslr for kdump is almost certainly useless (the
> amount of reserved memory is not enough to provide any meaningful
> randomization, so any randomization needs to happen during the memory
> reservation phase.) So disabling kaslr in the kdump kernel is entirely
> appropriate.
Peter covered everything already, but yeah, kaslr and kdump may not
make a lot of sense together, but regardless, yes, it only examines
e820 for memory space. It has to do all this work before the kernel
decompresses, so it's very early.
-Kees
--
Kees Cook
Chrome OS Security
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] x86 fixes
@ 2014-11-17 21:02 92% ` Kees Cook
0 siblings, 1 reply; 200+ results
From: Kees Cook @ 2014-11-17 21:02 UTC (permalink / raw)
To: Ingo Molnar
Cc: Markus Trippelsdorf, Junjie Mao, Linus Torvalds, LKML,
Thomas Gleixner, H. Peter Anvin, Borislav Petkov, Andrew Morton
On Mon, Nov 17, 2014 at 5:58 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Markus Trippelsdorf <markus@trippelsdorf.de> wrote:
>
>> On 2014.11.17 at 08:42 +0100, Markus Trippelsdorf wrote:
>> > On 2014.11.16 at 10:07 +0100, Ingo Molnar wrote:
>> > >
>> > > Junjie Mao (1):
>> > > x86, kaslr: Prevent .bss from overlaping initrd
>> >
>> > This breaks the build for me:
>> > ...
>> > OBJCOPY arch/x86/boot/compressed/vmlinux.bin
>> > HOSTCC arch/x86/boot/compressed/mkpiggy
>> > CC arch/x86/boot/compressed/cpuflags.o
>> > CC arch/x86/boot/version.o
>> > CC arch/x86/boot/video-vga.o
>> > CC arch/x86/boot/video-vesa.o
>> > CC arch/x86/boot/video-bios.o
>> > LZ4 arch/x86/boot/compressed/vmlinux.bin.lz4
>> > HOSTCC arch/x86/boot/tools/build
>> > CPUSTR arch/x86/boot/cpustr.h
>> > CC arch/x86/boot/cpu.o
>> > .bss and .brk lack common file offset
>> > .bss and .brk lack common file offset
>> > .bss and .brk lack common file offset
>> > .bss and .brk lack common file offset
>> > MKPIGGY arch/x86/boot/compressed/piggy.S
>> > Usage: arch/x86/boot/compressed/mkpiggy compressed_file run_size
>> > arch/x86/boot/compressed/Makefile:86: recipe for target 'arch/x86/boot/compressed/piggy.S' failed
>
> Oops ...
>
>> from my config:
>> # CONFIG_BLK_DEV_INITRD is not set
>>
>> So only running calc_run_size.pl when CONFIG_BLK_DEV_INITRD is set would
>> probably fix the issue.
>
> I've Cc:-ed Junjie Mao and Kees Cook as well.
Eek, well, the warning worked, at least (".bss and .brk lack common
file offset") since that was kind of an assumption in the script I
wanted to make sure we'd catch if it wasn't true.
Can you send your full .config? I built without CONFIG_BLK_DEV_INITRD,
and it didn't fail, so something else must be tickling this...
Sorry for the glitch!
-Kees
>
> Thanks,
>
> Ingo
--
Kees Cook
Chrome OS Security
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] x86 fixes
@ 2014-11-17 23:09 92% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2014-11-17 23:09 UTC (permalink / raw)
To: Markus Trippelsdorf
Cc: Ingo Molnar, Junjie Mao, Linus Torvalds, LKML, Thomas Gleixner,
H. Peter Anvin, Borislav Petkov, Andrew Morton
On Mon, Nov 17, 2014 at 1:21 PM, Markus Trippelsdorf
<markus@trippelsdorf.de> wrote:
> On 2014.11.17 at 13:02 -0800, Kees Cook wrote:
>>
>> Eek, well, the warning worked, at least (".bss and .brk lack common
>> file offset") since that was kind of an assumption in the script I
>> wanted to make sure we'd catch if it wasn't true.
>
> It depends on the linker being used. gold (my default) triggers the issue,
> ld.bfd is fine.
Ah-ha! Thanks, that did it for me. I've reproduced it and will get a
solution designed shortly.
-Kees
--
Kees Cook
Chrome OS Security
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] x86/mm changes for v4.4
@ 2015-11-08 6:58 91% ` Kees Cook
0 siblings, 1 reply; 200+ results
From: Kees Cook @ 2015-11-08 6:58 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Ingo Molnar, Matt Fleming, Linus Torvalds, Stephen Smalley,
Dave Jones, Linux Kernel Mailing List, Thomas Gleixner,
H. Peter Anvin, Borislav Petkov, Andrew Morton, Andy Lutomirski,
Denys Vlasenko, linux-efi, Matthew Garrett
On Fri, Nov 6, 2015 at 11:39 PM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> On 7 November 2015 at 08:09, Ingo Molnar <mingo@kernel.org> wrote:
>>
>> * Matt Fleming <matt@codeblueprint.co.uk> wrote:
>>
>>> On Fri, 06 Nov, at 07:55:50AM, Ingo Molnar wrote:
>>> >
>>> > 3) We should fix the EFI permission problem without relying on the firmware: it
>>> > appears we could just mark everything R-X optimistically, and if a write fault
>>> > happens (it's pretty rare in fact, only triggers when we write to an EFI
>>> > variable and so), we can mark the faulting page RW- on the fly, because it
>>> > appears that writable EFI sections, while not enumerated very well in 'old'
>>> > firmware, are still supposed to be page granular. (Even 'new' firmware I
>>> > wouldn't automatically trust to get the enumeration right...)
>>>
>>> Sorry, this isn't true. I misled you with one of my earlier posts on
>>> this topic. Let me try and clear things up...
>>>
>>> Writing to EFI regions has to do with every invocation of the EFI
>>> runtime services - it's not limited to when you read/write/delete EFI
>>> variables. In fact, EFI variables really have nothing to do with this
>>> discussion, they're a completely opaque concept to the OS, we have no
>>> idea how the firmware implements them. Everything is done via the EFI
>>> boot/runtime services.
>>>
>>> The firmware itself will attempt to write to EFI regions when we
>>> invoke the EFI services because that's where the PE/COFF ".data" and
>>> ".bss" sections live along with the heap. There's even some relocation
>>> fixups that occur as SetVirtualAddressMap() time so it'll write to
>>> ".text" too.
>>>
>>> Now, the above PE/COFF sections are usually (always?) contained within
>>> EFI regions of type EfiRuntimeServicesCode. We know this is true
>>> because the firmware folks have told us so, and because stopping that
>>> is the motivation behind the new EFI_PROPERTIES_TABLE feature in UEFI
>>> V2.5.
>>>
>>> The data sections within the region are also *not* guaranteed to be
>>> page granular because work was required in Tianocore for emitting
>>> sections with 4k alignment as part of the EFI_PROPERTIES_TABLE
>>> support.
>>>
>>> Ultimately, what this means is that if you were to attempt to
>>> dynamically fixup those regions that required write permission, you'd
>>> have to modify the mappings for the majority of the EFI regions
>>> anyway. And if you're blindly allowing write permission as a fixup,
>>> there's not much security to be had.
>>
>> I think you misunderstood my suggestion: the 'fixup' would be changing it from R-X
>> to RW-, i.e. it would add 'write' permission but remove 'execute' permission.
>>
>> Note that there would be no 'RWX' permission at any given moment - which is the
>> dangerous combination.
>>
>
> The problem with that is that /any/ page in the UEFI runtime region
> may intersect with both .text and .data of any of the PE/COFF images
> that make up the runtime firmware (since the PE/COFF sections are not
> necessarily page aligned). Such pages require RWX permissions. The
> UEFI memory map does not provide the information to identify those
> pages a priori (the entire region containing several PE/COFF images
> could be covered by a single entry) so it is hard to guess which pages
> should be allowed these RWX permissions.
I'm sad that UEFI was designed without even the most basic of memory
protections in mind. UEFI _itself_ should be setting up protective
page mappings. :(
For a boot firmware, it seems to me that safe page table layout would
be a top priority bug. The "reporting issues" page for TianoCore
doesn't actually seem to link to the "Project Tracker":
https://github.com/tianocore/tianocore.github.io/wiki/Reporting-Issues
Does anyone know how to get this correctly reported so future UEFI
releases don't suffer from this?
-Kees
>
>>> > If that 'supposed to be' turns out to be 'not true' (not unheard of in
>>> > firmware land), then plan B would be to mark pages that generate write faults
>>> > RWX as well, to not break functionality. (This 'mark it RWX' is not something
>>> > that exploits would have easy access to, and we could also generate a warning
>>> > [after the EFI call has finished] if it ever triggers.)
>>> >
>>> > Admittedly this approach might not be without its own complications, but it
>>> > looks reasonably simple (I don't think we need per EFI call page tables,
>>> > etc.), and does not assume much about the firmware being able to enumerate its
>>> > permissions properly. Were we to merge EFI support today I'd have insisted on
>>> > trying such an approach from day 1 on.
>>>
>>> We already have separate EFI page tables, though with the caveat that
>>> we share some of swapper_pg_dir's PGD entries. The best solution would
>>> be to stop sharing entries and isolate the EFI mappings from every
>>> other page table structure, so that they're only used during the EFI
>>> service calls.
>>
>> Absolutely. Can you try to fix this for v4.3?
>>
>> Thanks,
>>
>> Ingo
--
Kees Cook
Chrome OS Security
^ permalink raw reply [relevance 91%]
* Re: [GIT PULL] x86/mm changes for v4.4
@ 2015-11-09 21:08 92% ` Kees Cook
0 siblings, 1 reply; 200+ results
From: Kees Cook @ 2015-11-09 21:08 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Ingo Molnar, Matt Fleming, Linus Torvalds, Stephen Smalley,
Dave Jones, Linux Kernel Mailing List, Thomas Gleixner,
H. Peter Anvin, Borislav Petkov, Andrew Morton, Andy Lutomirski,
Denys Vlasenko, linux-efi, Matthew Garrett
On Sat, Nov 7, 2015 at 11:55 PM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> On 8 November 2015 at 07:58, Kees Cook <keescook@chromium.org> wrote:
>> On Fri, Nov 6, 2015 at 11:39 PM, Ard Biesheuvel
>> <ard.biesheuvel@linaro.org> wrote:
>>> On 7 November 2015 at 08:09, Ingo Molnar <mingo@kernel.org> wrote:
>>>>
>>>> * Matt Fleming <matt@codeblueprint.co.uk> wrote:
>>>>
>>>>> On Fri, 06 Nov, at 07:55:50AM, Ingo Molnar wrote:
>>>>> >
>>>>> > 3) We should fix the EFI permission problem without relying on the firmware: it
>>>>> > appears we could just mark everything R-X optimistically, and if a write fault
>>>>> > happens (it's pretty rare in fact, only triggers when we write to an EFI
>>>>> > variable and so), we can mark the faulting page RW- on the fly, because it
>>>>> > appears that writable EFI sections, while not enumerated very well in 'old'
>>>>> > firmware, are still supposed to be page granular. (Even 'new' firmware I
>>>>> > wouldn't automatically trust to get the enumeration right...)
>>>>>
>>>>> Sorry, this isn't true. I misled you with one of my earlier posts on
>>>>> this topic. Let me try and clear things up...
>>>>>
>>>>> Writing to EFI regions has to do with every invocation of the EFI
>>>>> runtime services - it's not limited to when you read/write/delete EFI
>>>>> variables. In fact, EFI variables really have nothing to do with this
>>>>> discussion, they're a completely opaque concept to the OS, we have no
>>>>> idea how the firmware implements them. Everything is done via the EFI
>>>>> boot/runtime services.
>>>>>
>>>>> The firmware itself will attempt to write to EFI regions when we
>>>>> invoke the EFI services because that's where the PE/COFF ".data" and
>>>>> ".bss" sections live along with the heap. There's even some relocation
>>>>> fixups that occur as SetVirtualAddressMap() time so it'll write to
>>>>> ".text" too.
>>>>>
>>>>> Now, the above PE/COFF sections are usually (always?) contained within
>>>>> EFI regions of type EfiRuntimeServicesCode. We know this is true
>>>>> because the firmware folks have told us so, and because stopping that
>>>>> is the motivation behind the new EFI_PROPERTIES_TABLE feature in UEFI
>>>>> V2.5.
>>>>>
>>>>> The data sections within the region are also *not* guaranteed to be
>>>>> page granular because work was required in Tianocore for emitting
>>>>> sections with 4k alignment as part of the EFI_PROPERTIES_TABLE
>>>>> support.
>>>>>
>>>>> Ultimately, what this means is that if you were to attempt to
>>>>> dynamically fixup those regions that required write permission, you'd
>>>>> have to modify the mappings for the majority of the EFI regions
>>>>> anyway. And if you're blindly allowing write permission as a fixup,
>>>>> there's not much security to be had.
>>>>
>>>> I think you misunderstood my suggestion: the 'fixup' would be changing it from R-X
>>>> to RW-, i.e. it would add 'write' permission but remove 'execute' permission.
>>>>
>>>> Note that there would be no 'RWX' permission at any given moment - which is the
>>>> dangerous combination.
>>>>
>>>
>>> The problem with that is that /any/ page in the UEFI runtime region
>>> may intersect with both .text and .data of any of the PE/COFF images
>>> that make up the runtime firmware (since the PE/COFF sections are not
>>> necessarily page aligned). Such pages require RWX permissions. The
>>> UEFI memory map does not provide the information to identify those
>>> pages a priori (the entire region containing several PE/COFF images
>>> could be covered by a single entry) so it is hard to guess which pages
>>> should be allowed these RWX permissions.
>>
>> I'm sad that UEFI was designed without even the most basic of memory
>> protections in mind. UEFI _itself_ should be setting up protective
>> page mappings. :(
>>
>
> Well, the 4 KB alignment of sections was considered prohibitive at the
> time from code size pov. But this was a long time ago, obviously.
Heh, yeah, I'd expect max 4K padding to get code/data correctly
aligned on a 2MB binary to not be an issue. :)
>
>> For a boot firmware, it seems to me that safe page table layout would
>> be a top priority bug. The "reporting issues" page for TianoCore
>> doesn't actually seem to link to the "Project Tracker":
>> https://github.com/tianocore/tianocore.github.io/wiki/Reporting-Issues
>>
>> Does anyone know how to get this correctly reported so future UEFI
>> releases don't suffer from this?
>>
>
> Ugh. Don't get me started on that topic. I have been working with the
> UEFI forum since July to get a fundamentally broken implementation of
> memory protections fixed. UEFI v2.5 defines a memory protection scheme
> that is based on splitting PE/COFF images into separate memory regions
> so that R-X and RW- permissions can be applied. Unfortunately, that
> broke every OS in existence (including Windows 8), since the OS is
> allowed to reorder memory regions when it lays out the virtual
> remapping of the UEFI regions, resulting in PE/COFF .data and .text
> potentially appearing out of order.
>
> The good news is that we fixed it for the upcoming release (v2.6). I
> can't disclose any specifics, though :-(
As long as there's motion to getting it fixed, that makes me happy! :)
Does 2.6 get rid of the (AIUI) 2MB limit too?
-Kees
>
> --
> Ard.
>
>
>>>>> > If that 'supposed to be' turns out to be 'not true' (not unheard of in
>>>>> > firmware land), then plan B would be to mark pages that generate write faults
>>>>> > RWX as well, to not break functionality. (This 'mark it RWX' is not something
>>>>> > that exploits would have easy access to, and we could also generate a warning
>>>>> > [after the EFI call has finished] if it ever triggers.)
>>>>> >
>>>>> > Admittedly this approach might not be without its own complications, but it
>>>>> > looks reasonably simple (I don't think we need per EFI call page tables,
>>>>> > etc.), and does not assume much about the firmware being able to enumerate its
>>>>> > permissions properly. Were we to merge EFI support today I'd have insisted on
>>>>> > trying such an approach from day 1 on.
>>>>>
>>>>> We already have separate EFI page tables, though with the caveat that
>>>>> we share some of swapper_pg_dir's PGD entries. The best solution would
>>>>> be to stop sharing entries and isolate the EFI mappings from every
>>>>> other page table structure, so that they're only used during the EFI
>>>>> service calls.
>>>>
>>>> Absolutely. Can you try to fix this for v4.3?
>>>>
>>>> Thanks,
>>>>
>>>> Ingo
>>
>>
>>
>> --
>> Kees Cook
>> Chrome OS Security
--
Kees Cook
Chrome OS Security
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] x86/mm changes for v4.4
@ 2015-11-10 20:11 92% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2015-11-10 20:11 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Ingo Molnar, Matt Fleming, Linus Torvalds, Stephen Smalley,
Dave Jones, Linux Kernel Mailing List, Thomas Gleixner,
H. Peter Anvin, Borislav Petkov, Andrew Morton, Andy Lutomirski,
Denys Vlasenko, linux-efi, Matthew Garrett
On Mon, Nov 9, 2015 at 11:08 PM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> On 9 November 2015 at 22:08, Kees Cook <keescook@chromium.org> wrote:
>> On Sat, Nov 7, 2015 at 11:55 PM, Ard Biesheuvel
>> <ard.biesheuvel@linaro.org> wrote:
>>> On 8 November 2015 at 07:58, Kees Cook <keescook@chromium.org> wrote:
>>>> On Fri, Nov 6, 2015 at 11:39 PM, Ard Biesheuvel
>>>> <ard.biesheuvel@linaro.org> wrote:
>>>>> On 7 November 2015 at 08:09, Ingo Molnar <mingo@kernel.org> wrote:
>>>>>>
>>>>>> * Matt Fleming <matt@codeblueprint.co.uk> wrote:
>>>>>>
>>>>>>> On Fri, 06 Nov, at 07:55:50AM, Ingo Molnar wrote:
>>>>>>> >
>>>>>>> > 3) We should fix the EFI permission problem without relying on the firmware: it
>>>>>>> > appears we could just mark everything R-X optimistically, and if a write fault
>>>>>>> > happens (it's pretty rare in fact, only triggers when we write to an EFI
>>>>>>> > variable and so), we can mark the faulting page RW- on the fly, because it
>>>>>>> > appears that writable EFI sections, while not enumerated very well in 'old'
>>>>>>> > firmware, are still supposed to be page granular. (Even 'new' firmware I
>>>>>>> > wouldn't automatically trust to get the enumeration right...)
>>>>>>>
>>>>>>> Sorry, this isn't true. I misled you with one of my earlier posts on
>>>>>>> this topic. Let me try and clear things up...
>>>>>>>
>>>>>>> Writing to EFI regions has to do with every invocation of the EFI
>>>>>>> runtime services - it's not limited to when you read/write/delete EFI
>>>>>>> variables. In fact, EFI variables really have nothing to do with this
>>>>>>> discussion, they're a completely opaque concept to the OS, we have no
>>>>>>> idea how the firmware implements them. Everything is done via the EFI
>>>>>>> boot/runtime services.
>>>>>>>
>>>>>>> The firmware itself will attempt to write to EFI regions when we
>>>>>>> invoke the EFI services because that's where the PE/COFF ".data" and
>>>>>>> ".bss" sections live along with the heap. There's even some relocation
>>>>>>> fixups that occur as SetVirtualAddressMap() time so it'll write to
>>>>>>> ".text" too.
>>>>>>>
>>>>>>> Now, the above PE/COFF sections are usually (always?) contained within
>>>>>>> EFI regions of type EfiRuntimeServicesCode. We know this is true
>>>>>>> because the firmware folks have told us so, and because stopping that
>>>>>>> is the motivation behind the new EFI_PROPERTIES_TABLE feature in UEFI
>>>>>>> V2.5.
>>>>>>>
>>>>>>> The data sections within the region are also *not* guaranteed to be
>>>>>>> page granular because work was required in Tianocore for emitting
>>>>>>> sections with 4k alignment as part of the EFI_PROPERTIES_TABLE
>>>>>>> support.
>>>>>>>
>>>>>>> Ultimately, what this means is that if you were to attempt to
>>>>>>> dynamically fixup those regions that required write permission, you'd
>>>>>>> have to modify the mappings for the majority of the EFI regions
>>>>>>> anyway. And if you're blindly allowing write permission as a fixup,
>>>>>>> there's not much security to be had.
>>>>>>
>>>>>> I think you misunderstood my suggestion: the 'fixup' would be changing it from R-X
>>>>>> to RW-, i.e. it would add 'write' permission but remove 'execute' permission.
>>>>>>
>>>>>> Note that there would be no 'RWX' permission at any given moment - which is the
>>>>>> dangerous combination.
>>>>>>
>>>>>
>>>>> The problem with that is that /any/ page in the UEFI runtime region
>>>>> may intersect with both .text and .data of any of the PE/COFF images
>>>>> that make up the runtime firmware (since the PE/COFF sections are not
>>>>> necessarily page aligned). Such pages require RWX permissions. The
>>>>> UEFI memory map does not provide the information to identify those
>>>>> pages a priori (the entire region containing several PE/COFF images
>>>>> could be covered by a single entry) so it is hard to guess which pages
>>>>> should be allowed these RWX permissions.
>>>>
>>>> I'm sad that UEFI was designed without even the most basic of memory
>>>> protections in mind. UEFI _itself_ should be setting up protective
>>>> page mappings. :(
>>>>
>>>
>>> Well, the 4 KB alignment of sections was considered prohibitive at the
>>> time from code size pov. But this was a long time ago, obviously.
>>
>> Heh, yeah, I'd expect max 4K padding to get code/data correctly
>> aligned on a 2MB binary to not be an issue. :)
>>
>
> This is not about section sizes on ARM. The PE/COFF format does not
> use segments, like ELF, so the payload (the sections) needs to be
> completely disjoint from the header. This means, when using 4 KB
> alignment, that every PE/COFF image wastes ~4 KB in the header and 4
> KB on average in the section padding (assuming a .text/.data/.reloc
> layout, as is common with PE/COFF)
>
> Considering that a typical UEFI firmware image consists of numerous
> (around 50 on average, I think) PE/COFF images, and some of them
Oooh, that's no fun. So the linker can't produce merged .text and
.data sections?
> execute from NOR flash, the Tianocore tooling (which is the reference
> implementation) has always been geared towards keeping the alignment
> as small as possible, typically 32 bytes unless data objects need
> more. Since the UEFI runtime services are typically implemented by
> several of these PE/COFF images, and since the memory they occupy may
> be described by a single UEFI memory map entry, there is simply no
> easy way to decide which pages need R-X, RW- or RWX. Even looking for
> PE/COFF headers in the memory region is not guaranteed to work, since
> the PE/COFF header is part of the file format, not the memory format
> (i.e., since the header is disjoint from the payload, a PE/COFF loader
> is not required to copy the header to memory)
>
>>>
>>>> For a boot firmware, it seems to me that safe page table layout would
>>>> be a top priority bug. The "reporting issues" page for TianoCore
>>>> doesn't actually seem to link to the "Project Tracker":
>>>> https://github.com/tianocore/tianocore.github.io/wiki/Reporting-Issues
>>>>
>>>> Does anyone know how to get this correctly reported so future UEFI
>>>> releases don't suffer from this?
>>>>
>>>
>>> Ugh. Don't get me started on that topic. I have been working with the
>>> UEFI forum since July to get a fundamentally broken implementation of
>>> memory protections fixed. UEFI v2.5 defines a memory protection scheme
>>> that is based on splitting PE/COFF images into separate memory regions
>>> so that R-X and RW- permissions can be applied. Unfortunately, that
>>> broke every OS in existence (including Windows 8), since the OS is
>>> allowed to reorder memory regions when it lays out the virtual
>>> remapping of the UEFI regions, resulting in PE/COFF .data and .text
>>> potentially appearing out of order.
>>>
>>> The good news is that we fixed it for the upcoming release (v2.6). I
>>> can't disclose any specifics, though :-(
>>
>> As long as there's motion to getting it fixed, that makes me happy! :)
>> Does 2.6 get rid of the (AIUI) 2MB limit too?
>>
>
> No, there is no such limit in UEFI. If there is a limit like that, it
> is an implementation detail of the UEFI support in the OS.
>
> For arm64 (and the upcoming ARM support), the UEFI runtime services
> regions are remapped into a virtual userland range that is only active
> during the time runtime services are being invoked. (x86 does
> something similar, but it shares the page tables with the
> suspend/resume code afaiu) These mappings could be page granularity
> (since they don't require splitting PUDs or PMDs in the linear
> region), with the side note that arm64 mandates 64 KB alignment (to
> interoperate with 64 KB pages OSes). This requirement has been added
> to the UEFI spec, i.e., a v2.5 compliant arm64 firmware should not
> expose UEFI runtime regions that are not 64 KB aligned.
Cool, thanks for the details!
-Kees
--
Kees Cook
Chrome OS Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] pstore updates for v4.8
@ 2016-07-25 21:31 88% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2016-07-25 21:31 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Geliang Tang, Greg Hackmann, Matt Fleming, Namhyung Kim
Hi,
This is my first pull request as the new pstore maintainer, so hopefully
I've followed all the correct best-practices. :) Please let me know if
I need to change anything about how I've constructed this pull request.
These are the updates for pstore, which expands the supported compressors,
fixes some bugs, and finally adds DT bindings.
Thanks!
-Kees
The following changes since commit 523d939ef98fd712632d93a5a2b588e477a7565e:
Linux 4.7 (2016-07-24 12:23:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/pstore-v4.8
for you to fetch changes up to 74e630a7582e6b3cb39559d712a0049f08dea8a0:
Merge tag 'v4.7' into for-linus/pstore (2016-07-25 13:50:36 -0700)
----------------------------------------------------------------
pstore subsystem updates for v4.8
----------------------------------------------------------------
Geliang Tang (3):
pstore: add lzo/lz4 compression support
pstore: drop file opened reference count
efi-pstore: implement efivars_pstore_exit()
Greg Hackmann (1):
pstore/ram: add Device Tree bindings
Kees Cook (2):
ramoops: Only unregister when registered
Merge tag 'v4.7' into for-linus/pstore
Namhyung Kim (2):
pstore: Enable compression on normal path (again)
pstore: Cleanup pstore_dump()
Documentation/devicetree/bindings/misc/ramoops.txt | 48 ++++
Documentation/ramoops.txt | 6 +-
arch/powerpc/kernel/nvram_64.c | 4 +-
drivers/acpi/apei/erst.c | 7 +-
drivers/firmware/efi/efi-pstore.c | 13 +
fs/pstore/Kconfig | 31 ++-
fs/pstore/inode.c | 1 -
fs/pstore/platform.c | 269 ++++++++++++++++++---
fs/pstore/ram.c | 105 +++++++-
include/linux/pstore.h | 3 +-
10 files changed, 436 insertions(+), 51 deletions(-)
create mode 100644 Documentation/devicetree/bindings/misc/ramoops.txt
--
Kees Cook
Brillo & Chrome OS Security
^ permalink raw reply [relevance 88%]
* [GIT PULL] usercopy protection for v4.8
@ 2016-07-26 21:55 81% Kees Cook
2016-07-27 3:53 92% ` Kees Cook
0 siblings, 1 reply; 200+ results
From: Kees Cook @ 2016-07-26 21:55 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Laura Abbott, Michael Ellerman, Valdis Kletnieks
Hi,
This is my next pull request for v4.8, which introduces a kernel self
protection of copy_to_user/copy_from_user that has been under review and
test on the kernel-hardening list for a while. It has lived for a bit
in -next, and appears to be ready IMO. There will be more improvements
in the future, but this is a solid start.
Again, if I can improve these pull request emails in any way, please
let me know. :)
Thanks!
-Kees
The following changes since commit 523d939ef98fd712632d93a5a2b588e477a7565e:
Linux 4.7 (2016-07-24 12:23:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/usercopy-v4.8
for you to fetch changes up to ed18adc1cdd00a5c55a20fbdaed4804660772281:
mm: SLUB hardened usercopy support (2016-07-26 14:43:54 -0700)
----------------------------------------------------------------
Implements HARDENED_USERCOPY verification of copy_to_user/copy_from_user
bounds checking for most architectures on SLAB and SLUB.
----------------------------------------------------------------
Kees Cook (11):
mm: Implement stack frame object validation
mm: Hardened usercopy
x86/uaccess: Enable hardened usercopy
ARM: uaccess: Enable hardened usercopy
arm64/uaccess: Enable hardened usercopy
ia64/uaccess: Enable hardened usercopy
powerpc/uaccess: Enable hardened usercopy
sparc/uaccess: Enable hardened usercopy
s390/uaccess: Enable hardened usercopy
mm: SLAB hardened usercopy support
mm: SLUB hardened usercopy support
Laura Abbott (1):
mm: Add is_migrate_cma_page
arch/Kconfig | 9 ++
arch/arm/Kconfig | 1 +
arch/arm/include/asm/uaccess.h | 11 +-
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/uaccess.h | 29 +++-
arch/arm64/kernel/arm64ksyms.c | 4 +-
arch/arm64/lib/copy_from_user.S | 4 +-
arch/arm64/lib/copy_to_user.S | 4 +-
arch/ia64/Kconfig | 1 +
arch/ia64/include/asm/uaccess.h | 18 ++-
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/uaccess.h | 21 ++-
arch/s390/Kconfig | 1 +
arch/s390/lib/uaccess.c | 2 +
arch/sparc/Kconfig | 1 +
arch/sparc/include/asm/uaccess_32.h | 14 +-
arch/sparc/include/asm/uaccess_64.h | 11 +-
arch/x86/Kconfig | 2 +
arch/x86/include/asm/thread_info.h | 44 ++++++
arch/x86/include/asm/uaccess.h | 10 +-
arch/x86/include/asm/uaccess_32.h | 2 +
arch/x86/include/asm/uaccess_64.h | 2 +
include/linux/mmzone.h | 2 +
include/linux/slab.h | 12 ++
include/linux/thread_info.h | 24 ++++
init/Kconfig | 2 +
mm/Makefile | 4 +
mm/slab.c | 30 ++++
mm/slub.c | 40 ++++++
mm/usercopy.c | 268 ++++++++++++++++++++++++++++++++++++
security/Kconfig | 28 ++++
31 files changed, 573 insertions(+), 30 deletions(-)
create mode 100644 mm/usercopy.c
--
Kees Cook
Brillo & Chrome OS Security
^ permalink raw reply [relevance 81%]
* Re: [GIT PULL] usercopy protection for v4.8
2016-07-26 21:55 81% [GIT PULL] usercopy protection " Kees Cook
@ 2016-07-27 3:53 92% ` Kees Cook
2016-07-30 4:36 92% ` Kees Cook
0 siblings, 1 reply; 200+ results
From: Kees Cook @ 2016-07-27 3:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: LKML, Laura Abbott, Michael Ellerman, Valdis Kletnieks
On Tue, Jul 26, 2016 at 2:55 PM, Kees Cook <keescook@chromium.org> wrote:
> Hi,
>
> This is my next pull request for v4.8, which introduces a kernel self
> protection of copy_to_user/copy_from_user that has been under review and
> test on the kernel-hardening list for a while. It has lived for a bit
> in -next, and appears to be ready IMO. There will be more improvements
> in the future, but this is a solid start.
>
> Again, if I can improve these pull request emails in any way, please
> let me know. :)
Hrm, part of the complexity of the KSPP work: this series depends on
_etext fixes in the arm and arm64 trees, so this should likely wait
until those trees are pulled.
-Kees
>
> Thanks!
>
> -Kees
>
> The following changes since commit 523d939ef98fd712632d93a5a2b588e477a7565e:
>
> Linux 4.7 (2016-07-24 12:23:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/usercopy-v4.8
>
> for you to fetch changes up to ed18adc1cdd00a5c55a20fbdaed4804660772281:
>
> mm: SLUB hardened usercopy support (2016-07-26 14:43:54 -0700)
>
> ----------------------------------------------------------------
> Implements HARDENED_USERCOPY verification of copy_to_user/copy_from_user
> bounds checking for most architectures on SLAB and SLUB.
>
> ----------------------------------------------------------------
> Kees Cook (11):
> mm: Implement stack frame object validation
> mm: Hardened usercopy
> x86/uaccess: Enable hardened usercopy
> ARM: uaccess: Enable hardened usercopy
> arm64/uaccess: Enable hardened usercopy
> ia64/uaccess: Enable hardened usercopy
> powerpc/uaccess: Enable hardened usercopy
> sparc/uaccess: Enable hardened usercopy
> s390/uaccess: Enable hardened usercopy
> mm: SLAB hardened usercopy support
> mm: SLUB hardened usercopy support
>
> Laura Abbott (1):
> mm: Add is_migrate_cma_page
>
> arch/Kconfig | 9 ++
> arch/arm/Kconfig | 1 +
> arch/arm/include/asm/uaccess.h | 11 +-
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/uaccess.h | 29 +++-
> arch/arm64/kernel/arm64ksyms.c | 4 +-
> arch/arm64/lib/copy_from_user.S | 4 +-
> arch/arm64/lib/copy_to_user.S | 4 +-
> arch/ia64/Kconfig | 1 +
> arch/ia64/include/asm/uaccess.h | 18 ++-
> arch/powerpc/Kconfig | 1 +
> arch/powerpc/include/asm/uaccess.h | 21 ++-
> arch/s390/Kconfig | 1 +
> arch/s390/lib/uaccess.c | 2 +
> arch/sparc/Kconfig | 1 +
> arch/sparc/include/asm/uaccess_32.h | 14 +-
> arch/sparc/include/asm/uaccess_64.h | 11 +-
> arch/x86/Kconfig | 2 +
> arch/x86/include/asm/thread_info.h | 44 ++++++
> arch/x86/include/asm/uaccess.h | 10 +-
> arch/x86/include/asm/uaccess_32.h | 2 +
> arch/x86/include/asm/uaccess_64.h | 2 +
> include/linux/mmzone.h | 2 +
> include/linux/slab.h | 12 ++
> include/linux/thread_info.h | 24 ++++
> init/Kconfig | 2 +
> mm/Makefile | 4 +
> mm/slab.c | 30 ++++
> mm/slub.c | 40 ++++++
> mm/usercopy.c | 268 ++++++++++++++++++++++++++++++++++++
> security/Kconfig | 28 ++++
> 31 files changed, 573 insertions(+), 30 deletions(-)
> create mode 100644 mm/usercopy.c
>
> --
> Kees Cook
> Brillo & Chrome OS Security
--
Kees Cook
Chrome OS & Brillo Security
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] usercopy protection for v4.8
2016-07-27 3:53 92% ` Kees Cook
@ 2016-07-30 4:36 92% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2016-07-30 4:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: LKML, Laura Abbott, Michael Ellerman, Valdis Kletnieks
On Tue, Jul 26, 2016 at 8:53 PM, Kees Cook <keescook@chromium.org> wrote:
> On Tue, Jul 26, 2016 at 2:55 PM, Kees Cook <keescook@chromium.org> wrote:
>> Hi,
>>
>> This is my next pull request for v4.8, which introduces a kernel self
>> protection of copy_to_user/copy_from_user that has been under review and
>> test on the kernel-hardening list for a while. It has lived for a bit
>> in -next, and appears to be ready IMO. There will be more improvements
>> in the future, but this is a solid start.
>>
>> Again, if I can improve these pull request emails in any way, please
>> let me know. :)
>
> Hrm, part of the complexity of the KSPP work: this series depends on
> _etext fixes in the arm and arm64 trees, so this should likely wait
> until those trees are pulled.
Okay, this should be ready to go now. The dependencies in arm and
arm64 have been pulled:
commit 14c4a533e09 ("ARM: 8583/1: mm: fix location of _etext")
commit 9fdc14c55cd6 ("arm64: mm: fix location of _etext")
Thanks!
-Kees
>> The following changes since commit 523d939ef98fd712632d93a5a2b588e477a7565e:
>>
>> Linux 4.7 (2016-07-24 12:23:50 -0700)
>>
>> are available in the git repository at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/usercopy-v4.8
>>
>> for you to fetch changes up to ed18adc1cdd00a5c55a20fbdaed4804660772281:
>>
>> mm: SLUB hardened usercopy support (2016-07-26 14:43:54 -0700)
>>
>> ----------------------------------------------------------------
>> Implements HARDENED_USERCOPY verification of copy_to_user/copy_from_user
>> bounds checking for most architectures on SLAB and SLUB.
>>
>> ----------------------------------------------------------------
>> Kees Cook (11):
>> mm: Implement stack frame object validation
>> mm: Hardened usercopy
>> x86/uaccess: Enable hardened usercopy
>> ARM: uaccess: Enable hardened usercopy
>> arm64/uaccess: Enable hardened usercopy
>> ia64/uaccess: Enable hardened usercopy
>> powerpc/uaccess: Enable hardened usercopy
>> sparc/uaccess: Enable hardened usercopy
>> s390/uaccess: Enable hardened usercopy
>> mm: SLAB hardened usercopy support
>> mm: SLUB hardened usercopy support
>>
>> Laura Abbott (1):
>> mm: Add is_migrate_cma_page
>>
>> arch/Kconfig | 9 ++
>> arch/arm/Kconfig | 1 +
>> arch/arm/include/asm/uaccess.h | 11 +-
>> arch/arm64/Kconfig | 1 +
>> arch/arm64/include/asm/uaccess.h | 29 +++-
>> arch/arm64/kernel/arm64ksyms.c | 4 +-
>> arch/arm64/lib/copy_from_user.S | 4 +-
>> arch/arm64/lib/copy_to_user.S | 4 +-
>> arch/ia64/Kconfig | 1 +
>> arch/ia64/include/asm/uaccess.h | 18 ++-
>> arch/powerpc/Kconfig | 1 +
>> arch/powerpc/include/asm/uaccess.h | 21 ++-
>> arch/s390/Kconfig | 1 +
>> arch/s390/lib/uaccess.c | 2 +
>> arch/sparc/Kconfig | 1 +
>> arch/sparc/include/asm/uaccess_32.h | 14 +-
>> arch/sparc/include/asm/uaccess_64.h | 11 +-
>> arch/x86/Kconfig | 2 +
>> arch/x86/include/asm/thread_info.h | 44 ++++++
>> arch/x86/include/asm/uaccess.h | 10 +-
>> arch/x86/include/asm/uaccess_32.h | 2 +
>> arch/x86/include/asm/uaccess_64.h | 2 +
>> include/linux/mmzone.h | 2 +
>> include/linux/slab.h | 12 ++
>> include/linux/thread_info.h | 24 ++++
>> init/Kconfig | 2 +
>> mm/Makefile | 4 +
>> mm/slab.c | 30 ++++
>> mm/slub.c | 40 ++++++
>> mm/usercopy.c | 268 ++++++++++++++++++++++++++++++++++++
>> security/Kconfig | 28 ++++
>> 31 files changed, 573 insertions(+), 30 deletions(-)
>> create mode 100644 mm/usercopy.c
>>
>> --
>> Kees Cook
>> Brillo & Chrome OS Security
>
>
>
> --
> Kees Cook
> Chrome OS & Brillo Security
--
Kees Cook
Chrome OS & Brillo Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] lkdtm update for v4.8-rc1
@ 2016-08-01 21:29 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2016-08-01 21:29 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel, Arnd Bergmann, Linus Torvalds
Hi,
Please pull these lkdtm fixes for v4.8-rc1.
Thanks!
-Kees
The following changes since commit 0e06f5c0deeef0332a5da2ecb8f1fcf3e024d958:
Merge branch 'akpm' (patches from Andrew) (2016-07-26 19:55:54 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/lkdtm-v4.8-rc1
for you to fetch changes up to e50bd2354ced2018eff1c7e06e7db4db1f5ce745:
lkdtm: Fix targets for objcopy usage (2016-08-01 14:27:24 -0700)
----------------------------------------------------------------
Fix rebuild problem with LKDTM's rodata test.
----------------------------------------------------------------
Kees Cook (2):
lkdtm: fix false positive warning from -Wmaybe-uninitialized
lkdtm: Fix targets for objcopy usage
drivers/misc/Makefile | 3 ++-
drivers/misc/lkdtm_usercopy.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
--
Kees Cook
Brillo & Chrome OS Security
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] kbuild changes for v4.8-rc1
@ 2016-08-02 20:55 92% ` Kees Cook
0 siblings, 1 reply; 200+ results
From: Kees Cook @ 2016-08-02 20:55 UTC (permalink / raw)
To: Linus Torvalds
Cc: Michal Marek, Arnd Bergmann, Emese Revfy, tautschn, Wolfram Sang,
Masahiro Yamada, Linux Kbuild mailing list,
Linux Kernel Mailing List
On Tue, Aug 2, 2016 at 1:41 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Tue, Aug 2, 2016 at 3:00 PM, Michal Marek <mmarek@suse.com> wrote:
>>
>> please merge these kbuild changes for v4.8-rc1:
>
> Merged. However, there were two slightly different versions of this
> commit in my tree:
>
>> Kees Cook (2):
>> kbuild: Abort build on bad stack protector flag
>
> differing by $ARCH vs $SRCARCH. There were a few other changes in that
> area too, so I'd really like you to verify the end result.
The version with $SRCARCH is the correct version. (I think akpm may
have picked up the v1, but Michal requested some changes that resulted
in the v2 with the $SRCARCH correction.)
--
Kees Cook
Chrome OS & Brillo Security
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] kbuild changes for v4.8-rc1
@ 2016-08-02 22:11 92% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2016-08-02 22:11 UTC (permalink / raw)
To: Linus Torvalds
Cc: Michal Marek, Arnd Bergmann, Emese Revfy, tautschn, Wolfram Sang,
Masahiro Yamada, Linux Kbuild mailing list,
Linux Kernel Mailing List
On Tue, Aug 2, 2016 at 2:00 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Tue, Aug 2, 2016 at 4:55 PM, Kees Cook <keescook@chromium.org> wrote:
>>
>> The version with $SRCARCH is the correct version. (I think akpm may
>> have picked up the v1, but Michal requested some changes that resulted
>> in the v2 with the $SRCARCH correction.)
>
> That's what I assumed, and that's the version I picked. There were
> some other confusing changes in that area though, so I'd like the
> involved people to give my resolution a second look, just to make sure
> it's fine.
Awesome, yeah, it looks good and tests out correctly for me.
Thanks!
-Kees
--
Kees Cook
Chrome OS & Brillo Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] gcc-plugins update for v4.8-rc1
@ 2016-08-02 22:20 83% Kees Cook
0 siblings, 1 reply; 200+ results
From: Kees Cook @ 2016-08-02 22:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Emese Revfy, Laura Abbott, PaX Team
Hi,
Please pull this new gcc-plugin for v4.8-rc1.
This is the next gcc plugin from Emese Revfy, funded by CII, and builds
on the new gcc-plugin infrastructure now present in Kbuild. It provides
a way to generate additional entropy at boot and runtime, which is
especially helpful for embedded systems.
Thanks!
-Kees
The following changes since commit 565910d28820376c6f20542922efcfddaaba11d0:
Merge remote-tracking branch 'kbuild/for-next' into for-next/gcc-plugins (2016-07-28 11:01:28 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/gcc-plugins-v4.8-rc1
for you to fetch changes up to 60c7930ac8443e1f6f72600c14faaa044a6d7725:
gcc-plugins: Add support for plugin subdirectories (2016-07-28 11:02:30 -0700)
----------------------------------------------------------------
New gcc plugin: latent_entropy for providing more boot entropy, especially
for embedded systems.
----------------------------------------------------------------
Emese Revfy (7):
kbuild: no gcc-plugins during cc-option tests
gcc-plugins: Add support for passing plugin arguments
gcc-plugins: Add latent_entropy plugin
latent_entropy: Mark functions with __latent_entropy
latent_entropy: Add the extra_latent_entropy kernel parameter
gcc-plugins: Automate make rule generation
gcc-plugins: Add support for plugin subdirectories
Kees Cook (1):
gcc-plugins: abort builds cleanly when not supported
Documentation/kernel-parameters.txt | 5 +
Makefile | 7 -
arch/Kconfig | 23 +
arch/powerpc/kernel/Makefile | 5 +
block/blk-softirq.c | 2 +-
drivers/char/random.c | 6 +-
fs/namespace.c | 1 +
include/linux/compiler-gcc.h | 7 +
include/linux/compiler.h | 4 +
include/linux/fdtable.h | 2 +-
include/linux/genhd.h | 2 +-
include/linux/init.h | 5 +-
include/linux/random.h | 15 +-
init/main.c | 1 +
kernel/fork.c | 7 +-
kernel/rcu/tiny.c | 2 +-
kernel/rcu/tree.c | 2 +-
kernel/sched/fair.c | 2 +-
kernel/softirq.c | 4 +-
kernel/time/timer.c | 2 +-
lib/irq_poll.c | 2 +-
lib/random32.c | 2 +-
mm/page_alloc.c | 32 ++
net/core/dev.c | 4 +-
scripts/Kbuild.include | 10 +-
scripts/Makefile.gcc-plugins | 45 +-
scripts/gcc-plugin.sh | 14 +
scripts/gcc-plugins/Makefile | 11 +-
scripts/gcc-plugins/latent_entropy_plugin.c | 639 ++++++++++++++++++++++++++++
29 files changed, 815 insertions(+), 48 deletions(-)
create mode 100644 scripts/gcc-plugins/latent_entropy_plugin.c
--
Kees Cook
Brillo & Chrome OS Security
^ permalink raw reply [relevance 83%]
* [GIT PULL] pstore fixes for v4.8-rc1
@ 2016-08-05 18:28 91% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2016-08-05 18:28 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Hiraku Toyooka, Nobuhiro Iwamatsu, Rob Herring
Hi,
Please pull these pstore fixes for v4.8-rc1.
This includes an adjustment to the DT bindings ramoops uses, as suggested
by Rob Herring, and fixes load failure memory clean up, from Hiraku Toyooka.
Thanks!
-Kees
The following changes since commit f38d2e5313f0af9d9b66c02a5d49c71deb994b85:
Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 (2016-08-01 14:28:42 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/pstore-v4.8-rc1
for you to fetch changes up to e976e56423dc1cc01686861fc3e0c6c0ec8cd8b7:
ramoops: use persistent_ram_free() instead of kfree() for freeing prz (2016-08-05 11:21:46 -0700)
----------------------------------------------------------------
Fixes for pstore ramoops driver to catch bad kfree() and to use better DT
bindings.
----------------------------------------------------------------
Hiraku Toyooka (1):
ramoops: use persistent_ram_free() instead of kfree() for freeing prz
Kees Cook (1):
ramoops: use DT reserved-memory bindings
.../bindings/{misc => reserved-memory}/ramoops.txt | 8 ++---
Documentation/ramoops.txt | 38 +++++++++++++++-------
drivers/of/platform.c | 20 ++++++++++--
fs/pstore/ram.c | 29 ++++++-----------
4 files changed, 59 insertions(+), 36 deletions(-)
rename Documentation/devicetree/bindings/{misc => reserved-memory}/ramoops.txt (86%)
--
Kees Cook
Brillo & Chrome OS Security
^ permalink raw reply [relevance 91%]
* Re: [GIT PULL] gcc-plugins update for v4.8-rc1
@ 2016-08-08 23:18 69% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2016-08-08 23:18 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, Emese Revfy, Laura Abbott, PaX Team
On Mon, Aug 8, 2016 at 3:38 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Tue, Aug 2, 2016 at 3:20 PM, Kees Cook <keescook@chromium.org> wrote:
>>
>> Please pull this new gcc-plugin for v4.8-rc1.
>
> So I'm not pulling this for four reasons:
>
> (a) most of it is back-merges. There are 8 actual commits - but they
> are preceded by 11 pointless merges of the kbuild branch. No thank
> you.
This was an artifact of development and handling the kbuild maintainer
being on vacation during some of the time. I tried to follow sfr's
advice on best-practices for linux-next, but I guess this didn't work
well. Should I rebase on v4.8-rc1 to clean this up, or is there
something else I can do to make the merges cleaner?
> (b) of the eight actual commits, five are not about the new entropy
> plugin at all, but are generic plugin fixes. Why did those not go
> through the plugin support tree? I get the strong feeling that the
> plugin infrastructure wasn't actually ready.
In theory, this tree is the plugin support tree (now that the core
infrastructure landed by way of the kbuild tree). Perhaps I'm
misunderstanding the segregation of responsibilities on this, though.
(Or maybe I need to add scripts/Makefile.gcc-plugins to the
gcc-plugins section in the MAINTAINERS file?) FWIW, the five clean ups
were identified either during linux-next time (see vacation note
above), or were added to support new plugin features (e.g. the initify
plugin which hasn't yet entered linux-next).
> (c) Of the four remaining commits that actually add entropy, the
> "extra_latent_entropy" thing isn't about the gcc plugin at all, but
> has a pointless "klet's mix it into the plugin pool" code under an
> #ifdef. For no possible reason I can see.
Since it had some dependency on the plugin, this seemed the right
place to land it. I could certainly clean up the code to avoid an
#ifdef in the .c file, if that is of particular note. The reason for
the hash mixing there is to further perturb the latent_entropy value
based on the (possibly warm or otherwise unpredictable) physical
memory contents.
> (d) you don't actually describe what the plugin does in the pull
> request. I had to try to figure it out from reading the commit and the
Fair enough, I can improve the description quite a bit more in the
pull request (and in other places, see below).
> plugin code. And quite frankly, even then it is not actually at all
> obvious to me that this adds any real entropy at all in the situation
> that actually matters most - the embedded "everythingsis the same, and
> everybody uses the same build" situation.
It is certainly hard to measure, but given the instrumentation of
things like interrupt code, loops, and other control flow primitives,
there is unpredictability being added even on identical builds on the
same hardware.
> From what I can tell, 990% of the "entropy" this adds is about
> build-time things (random numbers generated at build-time), and the
> only real runtime entropy it adds comes from the frame pointer. And
> that may well be identical from boot to boot when there are no real
> timing differences.
The build time entropy is used to create the palette of available
random numbers that get mixed into the latent entropy hash. These are
mixed into the RNG pool based on the results of control flow, SMP
ordering, etc.
> The build-time random numbers are just pure garbage. There is *no*
> entropy in them for the situation that matters most. You might as well
> just generate one single random number at build-time without any fancy
> new compiler plugin thing.
Well, no, as mentioned above: runtime patterns do change the resulting
latent entropy. Note that the code does not credit any entropy to the
pool, it just mixes in the bytes, resulting in greater
unpredictability.
> On a real PC, this plugin doesn't seem to matter, so it really seems
> to be mostly about embedded hw without good sources of entropy. But
> I'd really want to hear why such a platform would get noticeably more
> entropy from the frame pointer games.
While the benefits here are primarily focused on early boot
randomness, as the system runs, the unpredictability continues to
slowly get fed into the RNG pool. Think of it as a low-entropy RNG
input.
> So quite honestly, a lot of this smells very much like "security
> theater" to me. Fancy code that makes things look really complex and
> fancy. But where much of it seems to be quite dubious.
It's not theater in the sense that it does measurably improve entropy
on low-entropy devices, and that it doesn't claim to be "real" entropy
(in that it credits 0 bytes per input).
> What are we going to do next? Ask people to remove their shoes while
> compiling the kernel in the name of "security"?
:P For what it's worth, even having the static pre-populated per-build
randomness added to the pools can spoil RNG prediction attempts,
especially if a kernel is being updated regularly (as done by distros,
Android, etc).
> Tell me I'm wrong. Tell me I misread the plugin, and it's stronger
> than my reading implies.
I know you're generally pretty conservative about security changes,
but I think it's stronger than you think it is. I'm not going to claim
it's a magic bullet, but then it doesn't claim that either. It's an
improvement for several use-cases, and is tidily in the corner as a
gcc plugin, so it shouldn't get in the way of a traditional build.
> But that would just be a stronger argument for actually having a
> description of what the plugin does. See my point (d) above.
I tried to help Emese with more verbose commit messages. It sounds
like the commit message in "gcc-plugins: Add latent_entropy plugin"
wasn't sufficient (and that the comments in
scripts/gcc-plugins/latent_entropy_plugin.c aren't sufficient either).
I'm happy to adjust whatever you'd like. :) Where do you think it
would be best to increase verbosity? All of the above (i.e. code
comments, commit message, and pull request message) or just focus on
one area?
As for timing, this code has seen a fair bit of testing (on multiple
architectures) while living in linux-next, so I consider it
operationally ready. If I can clean up the comments/commit logs and
you're otherwise satisfied with my descriptions, would you still
consider this for v4.8 or do you want this delayed beyond v4.8?
Thanks!
-Kees
--
Kees Cook
Nexus Security
^ permalink raw reply [relevance 69%]
* [GIT PULL] gcc-plugin-infrastructure updates for v4.8-rc2
@ 2016-08-09 1:04 91% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2016-08-09 1:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Emese Revfy, Laura Abbott, PaX Team, linux-kernel
The following changes since commit 574673c231a5fad1560249cc3a598907acb36cf9:
printk: Remove unnecessary #ifdef CONFIG_PRINTK (2016-08-08 11:29:39 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/gcc-plugin-infrastructure-v4.8-rc2
for you to fetch changes up to caefd8c9a9fb06811e07bf3571e5d4450846b16a:
gcc-plugins: Add support for plugin subdirectories (2016-08-08 17:53:05 -0700)
----------------------------------------------------------------
Several fixes/improvements for the gcc plugin infrastructure:
- Fixes a problem with gcc plugins interfering with cc-option tests.
- Aborts more gracefully when gcc plugin headers or compiler support is
missing.
- Improves the gcc plugin rule generation to be more dynamic, pass arguments,
and build from subdirectories.
----------------------------------------------------------------
Emese Revfy (4):
kbuild: no gcc-plugins during cc-option tests
gcc-plugins: Add support for passing plugin arguments
gcc-plugins: Automate make rule generation
gcc-plugins: Add support for plugin subdirectories
Kees Cook (1):
gcc-plugins: abort builds cleanly when not supported
Makefile | 7 -------
scripts/Kbuild.include | 10 +++++++---
scripts/Makefile.gcc-plugins | 39 ++++++++++++++++++++++++++++-----------
scripts/gcc-plugin.sh | 14 ++++++++++++++
scripts/gcc-plugins/Makefile | 12 +++++++-----
5 files changed, 56 insertions(+), 26 deletions(-)
--
Kees Cook
Nexus Security
^ permalink raw reply [relevance 91%]
* [GIT PULL] hardened usercopy fixes for v4.8-rc4
@ 2016-08-23 2:22 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2016-08-23 2:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Eric Biggers, Josh Poimboeuf
Hi,
Please pull these hardened usercopy fixes for v4.8-rc4.
Thanks!
-Kees
The following changes since commit ef0e1ea8856bed6ff8394d3dfe77f2cab487ecea:
Merge tag 'arc-4.8-rc4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc (2016-08-22 17:53:02 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/usercopy-v4.8-rc4
for you to fetch changes up to 94cd97af690dd9537818dc9841d0ec68bb1dd877:
usercopy: fix overlap check for kernel text (2016-08-22 19:10:51 -0700)
----------------------------------------------------------------
Fixes for hardened usercopy:
- avoid signed math problems on unexpected compilers
- avoid false positives at very end of kernel text range checks
----------------------------------------------------------------
Eric Biggers (1):
usercopy: avoid potentially undefined behavior in pointer math
Josh Poimboeuf (1):
usercopy: fix overlap check for kernel text
mm/usercopy.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
Kees Cook
Nexus Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] seccomp fix for v4.8-rc4
@ 2016-08-23 19:34 92% Kees Cook
2016-08-30 22:28 92% ` Kees Cook
0 siblings, 1 reply; 200+ results
From: Kees Cook @ 2016-08-23 19:34 UTC (permalink / raw)
To: James Morris
Cc: linux-kernel, Kees Cook, Kyle Huey, Oleg Nesterov, Robert O'Callahan
Hi,
Please pull this seccomp fix for v4.8-rc4.
Thanks!
-Kees
The following changes since commit ef0e1ea8856bed6ff8394d3dfe77f2cab487ecea:
Merge tag 'arc-4.8-rc4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc (2016-08-22 17:53:02 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-v4.8-rc4
for you to fetch changes up to e72a2623bf56a94e1396940d73bf7af7b65e0ea5:
seccomp: Fix tracer exit notifications during fatal signals (2016-08-23 12:23:38 -0700)
----------------------------------------------------------------
Fix fatal signal delivery after ptrace reordering
----------------------------------------------------------------
Kees Cook (1):
seccomp: Fix tracer exit notifications during fatal signals
kernel/seccomp.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
--
Kees Cook
Nexus Security
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] seccomp fix for v4.8-rc4
2016-08-23 19:34 92% [GIT PULL] seccomp fix " Kees Cook
@ 2016-08-30 22:28 92% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2016-08-30 22:28 UTC (permalink / raw)
To: James Morris
Cc: LKML, Kees Cook, Kyle Huey, Oleg Nesterov, Robert O'Callahan
Hi James,
Are you able to forward this up to Linus, or would it be better for me
to send this to him directly?
Thanks!
-Kees
On Tue, Aug 23, 2016 at 3:34 PM, Kees Cook <keescook@chromium.org> wrote:
> Hi,
>
> Please pull this seccomp fix for v4.8-rc4.
>
> Thanks!
>
> -Kees
>
> The following changes since commit ef0e1ea8856bed6ff8394d3dfe77f2cab487ecea:
>
> Merge tag 'arc-4.8-rc4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc (2016-08-22 17:53:02 -0500)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-v4.8-rc4
>
> for you to fetch changes up to e72a2623bf56a94e1396940d73bf7af7b65e0ea5:
>
> seccomp: Fix tracer exit notifications during fatal signals (2016-08-23 12:23:38 -0700)
>
> ----------------------------------------------------------------
> Fix fatal signal delivery after ptrace reordering
>
> ----------------------------------------------------------------
> Kees Cook (1):
> seccomp: Fix tracer exit notifications during fatal signals
>
> kernel/seccomp.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> --
> Kees Cook
> Nexus Security
--
Kees Cook
Nexus Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] seccomp fix for v4.8-rc5
@ 2016-08-30 23:15 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2016-08-30 23:15 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, James Morris, Kyle Huey, Oleg Nesterov,
Robert O'Callahan
Hi,
Please pull this seccomp fix for v4.8-rc5.
Thanks!
-Kees
The following changes since commit ef0e1ea8856bed6ff8394d3dfe77f2cab487ecea:
Merge tag 'arc-4.8-rc4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc (2016-08-22 17:53:02 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-v4.8-rc5
for you to fetch changes up to 485a252a5559b45d7df04c819ec91177c62c270b:
seccomp: Fix tracer exit notifications during fatal signals (2016-08-30 16:12:46 -0700)
----------------------------------------------------------------
Fix fatal signal delivery after ptrace reordering.
----------------------------------------------------------------
Kees Cook (1):
seccomp: Fix tracer exit notifications during fatal signals
kernel/seccomp.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
--
Kees Cook
Nexus Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] usercopy fixes for v4.8-rc6
@ 2016-09-06 19:37 91% Kees Cook
0 siblings, 1 reply; 200+ results
From: Kees Cook @ 2016-09-06 19:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, x86
Hi,
Please pull these usercopy fixes for v4.8-rc6.
Thanks!
-Kees
The following changes since commit 46738ab31fe668ea1d4413dd459af2632f6fef8d:
Merge branch 'mailbox-devel' of git://git.linaro.org/landing-teams/working/fujitsu/integration (2016-09-06 11:15:07 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/usercopy-v4.8-rc6
for you to fetch changes up to 3c17648c2816f6d28bd2be9293032a2901994a36:
lkdtm: adjust usercopy tests to bypass const checks (2016-09-06 12:17:30 -0700)
----------------------------------------------------------------
- Inlines copy_*_user() for correct use of __builtin_const_p() for hardened
usercopy and the recent compile-time checks.
- Switches hardened usercopy to only check non-const size arguments to avoid
meaningless checks on likely-sane const values.
- Updates lkdtm usercopy tests to compenstate for the const checking.
----------------------------------------------------------------
Kees Cook (3):
x86/uaccess: force copy_*_user() to be inlined
usercopy: fold builtin_const check into inline function
lkdtm: adjust usercopy tests to bypass const checks
arch/ia64/include/asm/uaccess.h | 12 ++++--------
arch/powerpc/include/asm/uaccess.h | 19 +++++++------------
arch/sparc/include/asm/uaccess_32.h | 9 +++------
arch/sparc/include/asm/uaccess_64.h | 7 +++----
arch/x86/include/asm/uaccess.h | 4 ++--
drivers/misc/lkdtm_usercopy.c | 25 +++++++++++++++++--------
include/linux/thread_info.h | 3 ++-
7 files changed, 38 insertions(+), 41 deletions(-)
--
Kees Cook
Nexus Security
^ permalink raw reply [relevance 91%]
* [GIT PULL] seccomp fixes for v4.8-rc6
@ 2016-09-07 16:29 92% Kees Cook
0 siblings, 1 reply; 200+ results
From: Kees Cook @ 2016-09-07 16:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, James Morris, Mickaël Salaün
Hi,
Please pull these seccomp fixes for v4.8-rc6. These got accidentally
put in James's -next tree, but they're needed for v4.8. He asked me to
forward them directly to you.
Thanks!
-Kees
The following changes since commit d060e0f603a4156087813d221d818bb39ec91429:
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma (2016-09-06 12:33:12 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-v4.8-rc6
for you to fetch changes up to 4fadd04d504a82f7f1fdeaddc144a9c396d1285e:
seccomp: Remove 2-phase API documentation (2016-09-07 09:25:05 -0700)
----------------------------------------------------------------
- Fix UM seccomp vs ptrace, after reordering landed.
----------------------------------------------------------------
Mickaël Salaün (3):
um/ptrace: Fix the syscall_trace_leave call
um/ptrace: Fix the syscall number update after a ptrace
seccomp: Remove 2-phase API documentation
arch/Kconfig | 11 -----------
arch/um/kernel/skas/syscall.c | 10 +++-------
arch/x86/um/ptrace_32.c | 3 +++
arch/x86/um/ptrace_64.c | 4 ++++
4 files changed, 10 insertions(+), 18 deletions(-)
--
Kees Cook
Nexus Security
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] usercopy fixes for v4.8-rc6
@ 2016-09-07 16:38 92% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2016-09-07 16:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List, the arch/x86 maintainers
On Wed, Sep 7, 2016 at 9:33 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> Pulled, but:
>
> On Tue, Sep 6, 2016 at 12:37 PM, Kees Cook <keescook@chromium.org> wrote:
>>
>> Kees Cook (3):
>> usercopy: fold builtin_const check into inline function
>
> Hmm. So with this, check_object_size() seems sane, but it's only
> marked "inline".
>
> And we've had the issue that without the __always_inline, gcc will
> randomly not inline things. In fact, this very pull added that to the
Yeah, reading the thread from 2009 made my head spin. :(
> copy_xyz_user() functions exactly because of this issue.
>
> Now, it may be that check_object_size() is so simple that it really
> always *will* be inlined regardless, but it looks a bit dodgy.
True, yes. I will send another update with that added.
(And a heads-up: another part of the update will be the disabling
hardened usercopy's page-spanning checker too -- we've had another
false positive hit on that, so it's time to drop it.)
Thanks!
-Kees
--
Kees Cook
Nexus Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] usercopy fixes for v4.8-rc6-part2
@ 2016-09-07 18:36 92% Kees Cook
0 siblings, 1 reply; 200+ results
From: Kees Cook @ 2016-09-07 18:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Vinson Lee
Hi,
Please pull these usercopy fixes for v4.8-rc6-part2.
Thanks!
-Kees
The following changes since commit ab29b33a84f6910ebf01a32f69a370886a4283dd:
Merge tag 'seccomp-v4.8-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux (2016-09-07 10:46:06 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/usercopy-v4.8-rc6-part2
for you to fetch changes up to 8e1f74ea02cf4562404c48c6882214821552c13f:
usercopy: remove page-spanning test for now (2016-09-07 11:33:26 -0700)
----------------------------------------------------------------
- force check_object_size() to be inline too
- move page-spanning check behind a CONFIG since it's triggering false positives
----------------------------------------------------------------
Kees Cook (2):
usercopy: force check_object_size() inline
usercopy: remove page-spanning test for now
include/linux/thread_info.h | 4 +--
mm/usercopy.c | 61 ++++++++++++++++++++++++++-------------------
security/Kconfig | 11 ++++++++
3 files changed, 48 insertions(+), 28 deletions(-)
--
Kees Cook
Nexus Security
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] usercopy fixes for v4.8-rc6-part2
@ 2016-09-07 21:32 92% ` Kees Cook
2016-09-07 21:48 92% ` Kees Cook
0 siblings, 1 reply; 200+ results
From: Kees Cook @ 2016-09-07 21:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List, Vinson Lee
On Wed, Sep 7, 2016 at 12:15 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Wed, Sep 7, 2016 at 11:36 AM, Kees Cook <keescook@chromium.org> wrote:
>>
>> - move page-spanning check behind a CONFIG since it's triggering false positives
>
> Hmm. I pulled this, but looking at it I realized that
>
> + depends on !COMPILE_TEST
>
> doesn't make any real sense to me.
>
> All it does is make sure that "make allmodconfig" doesn't actually
> test that the PAGESPAN code compiles.
>
> It's not like that is a big cost for allmodconfig builds, but it does
> mean that it gets less coverage.
>
> And it really makes no sense to me. We *don't* want to run with that
> option enabled normally.
>
> I think what you actually meant was something like
>
> + depends on EXPERT
>
> which means that it does *not* get enabled in normal user builds.
>
> Hmm?
I guess that's true -- I was trying to think of a way to make sure it
didn't get tested by 0-day syscall fuzzer on a randconfig, since I
didn't want the noise. But now that I double-check this, yeah, it
looks like randconfig doesn't set COMPILE_TEST. Hmpf.
I will send another patch to flip this to EXPERT, and if 0-day finds
issues, I can add them to the __GPF_COMP hit-list. :P
-Kees
--
Kees Cook
Nexus Security
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] usercopy fixes for v4.8-rc6-part2
2016-09-07 21:32 92% ` Kees Cook
@ 2016-09-07 21:48 92% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2016-09-07 21:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List, Vinson Lee
On Wed, Sep 7, 2016 at 2:32 PM, Kees Cook <keescook@chromium.org> wrote:
> On Wed, Sep 7, 2016 at 12:15 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>> On Wed, Sep 7, 2016 at 11:36 AM, Kees Cook <keescook@chromium.org> wrote:
>>>
>>> - move page-spanning check behind a CONFIG since it's triggering false positives
>>
>> Hmm. I pulled this, but looking at it I realized that
>>
>> + depends on !COMPILE_TEST
>>
>> doesn't make any real sense to me.
>>
>> All it does is make sure that "make allmodconfig" doesn't actually
>> test that the PAGESPAN code compiles.
>>
>> It's not like that is a big cost for allmodconfig builds, but it does
>> mean that it gets less coverage.
>>
>> And it really makes no sense to me. We *don't* want to run with that
>> option enabled normally.
>>
>> I think what you actually meant was something like
>>
>> + depends on EXPERT
>>
>> which means that it does *not* get enabled in normal user builds.
>>
>> Hmm?
>
> I guess that's true -- I was trying to think of a way to make sure it
> didn't get tested by 0-day syscall fuzzer on a randconfig, since I
> didn't want the noise. But now that I double-check this, yeah, it
> looks like randconfig doesn't set COMPILE_TEST. Hmpf.
>
> I will send another patch to flip this to EXPERT, and if 0-day finds
> issues, I can add them to the __GPF_COMP hit-list. :P
Oh! Nevermind, I see you did that already. Thank you! :)
-Kees
--
Kees Cook
Nexus Security
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] seccomp fixes for v4.8-rc6
@ 2016-09-08 15:53 92% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2016-09-08 15:53 UTC (permalink / raw)
To: James Morris; +Cc: Linus Torvalds, LKML, Mickaël Salaün
On Wed, Sep 7, 2016 at 9:31 PM, James Morris <james.l.morris@oracle.com> wrote:
> Actually I asked if you could send them to me...
Oh, whoops! Sorry for the mix-up.
-Kees
>
>
>
> On 08/09/16 02:29, Kees Cook wrote:
>>
>> Hi,
>>
>> Please pull these seccomp fixes for v4.8-rc6. These got accidentally
>> put in James's -next tree, but they're needed for v4.8. He asked me to
>> forward them directly to you.
>>
>> Thanks!
>>
>> -Kees
>>
>> The following changes since commit
>> d060e0f603a4156087813d221d818bb39ec91429:
>>
>> Merge tag 'for-linus' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma (2016-09-06
>> 12:33:12 -0700)
>>
>> are available in the git repository at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git
>> tags/seccomp-v4.8-rc6
>>
>> for you to fetch changes up to 4fadd04d504a82f7f1fdeaddc144a9c396d1285e:
>>
>> seccomp: Remove 2-phase API documentation (2016-09-07 09:25:05 -0700)
>>
>> ----------------------------------------------------------------
>> - Fix UM seccomp vs ptrace, after reordering landed.
>>
>> ----------------------------------------------------------------
>> Mickaël Salaün (3):
>> um/ptrace: Fix the syscall_trace_leave call
>> um/ptrace: Fix the syscall number update after a ptrace
>> seccomp: Remove 2-phase API documentation
>>
>> arch/Kconfig | 11 -----------
>> arch/um/kernel/skas/syscall.c | 10 +++-------
>> arch/x86/um/ptrace_32.c | 3 +++
>> arch/x86/um/ptrace_64.c | 4 ++++
>> 4 files changed, 10 insertions(+), 18 deletions(-)
>>
>
--
Kees Cook
Nexus Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] usercopy fix for v4.8-rc8
@ 2016-09-20 23:15 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2016-09-20 23:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Laura Abbott
Hi,
Please pull this usercopy fix for v4.8-rc8. Another fix-up for arm64.
Thanks!
-Kees
The following changes since commit d2ffb0103aaefa9b169da042cf39ce27bfb6cdbb:
Merge branch 'akpm' (patches from Andrew) (2016-09-19 16:08:03 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/usercopy-v4.8-rc8
for you to fetch changes up to aa4f0601115319a52c80f468c8f007e5aa9277cb:
mm: usercopy: Check for module addresses (2016-09-20 16:07:39 -0700)
----------------------------------------------------------------
- expand the arm64 vmalloc check to include skipping the module space too
----------------------------------------------------------------
Laura Abbott (1):
mm: usercopy: Check for module addresses
mm/usercopy.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--
Kees Cook
Nexus Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] pstore updates for v4.9-rc1
@ 2016-10-05 21:43 86% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2016-10-05 21:43 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Aaron Durbin, Andrew Bresticker,
Enric Balletbo Serra, Furquan Shaikh, Furquan Shaikh,
Geliang Tang, Guenter Roeck, Kees Cook, Mark Salyzyn,
Namhyung Kim, Olof Johansson, Puneet Kumar, Rabin Vincent,
Sebastian Andrzej Siewior
Hi,
Please pull these pstore changes for v4.9-rc1.
Thanks!
-Kees
The following changes since commit d71f058617564750261b673ea9b3352382b9cde4:
Merge branch 'for-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux (2016-09-07 21:28:26 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/pstore-v4.9-rc1
for you to fetch changes up to f88baf68ebe5b2efced64725fd98548af9b8f510:
ramoops: move spin_lock_init after kmalloc error checking (2016-09-08 15:01:13 -0700)
----------------------------------------------------------------
Fix bug in module unloading.
Switch to always using spinlock over cmpxchg.
Explicitly define pstore backend's supported modes.
Remove bounce buffer from pmsg.
Switch to using memcpy_to/fromio().
Error checking improvements.
----------------------------------------------------------------
Andrew Bresticker (1):
pstore/ram: Use memcpy_fromio() to save old buffer
Furquan Shaikh (1):
pstore/ram: Use memcpy_toio instead of memcpy
Geliang Tang (1):
ramoops: move spin_lock_init after kmalloc error checking
Mark Salyzyn (1):
pstore/pmsg: drop bounce buffer
Namhyung Kim (2):
pstore: Split pstore fragile flags
pstore/ram: Set pstore flags dynamically
Sebastian Andrzej Siewior (2):
pstore/ramoops: fixup driver removal
pstore/core: drop cmpxchg based updates
drivers/acpi/apei/erst.c | 2 +-
drivers/firmware/efi/efi-pstore.c | 2 +-
fs/pstore/platform.c | 53 ++++++++++++++++++---
fs/pstore/pmsg.c | 35 +++-----------
fs/pstore/ram.c | 46 ++++++++++++++++---
fs/pstore/ram_core.c | 96 ++++++++++++++++++++-------------------
include/linux/pstore.h | 17 +++++--
include/linux/pstore_ram.h | 7 ++-
8 files changed, 162 insertions(+), 96 deletions(-)
--
Kees Cook
Nexus Security
^ permalink raw reply [relevance 86%]
* [GIT PULL] gcc-plugins updates for v4.9-rc1
@ 2016-10-10 22:04 87% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2016-10-10 22:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Emese Revfy, Kees Cook
Hi,
Please pull these gcc-plugins changes for v4.9-rc1.
Thanks!
-Kees
The following changes since commit c8d2bc9bc39ebea8437fd974fdbc21847bb897a3:
Linux 4.8 (2016-10-02 16:24:33 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/gcc-plugins-v4.9-rc1
for you to fetch changes up to 0766f788eb727e2e330d55d30545db65bcf2623f:
latent_entropy: Mark functions with __latent_entropy (2016-10-10 14:51:45 -0700)
----------------------------------------------------------------
This adds a new gcc plugin named "latent_entropy". It is designed to
extract as much possible uncertainty from a running system at boot time as
possible, hoping to capitalize on any possible variation in CPU operation
(due to runtime data differences, hardware differences, SMP ordering,
thermal timing variation, cache behavior, etc).
At the very least, this plugin is a much more comprehensive example for
how to manipulate kernel code using the gcc plugin internals.
----------------------------------------------------------------
Emese Revfy (2):
gcc-plugins: Add latent_entropy plugin
latent_entropy: Mark functions with __latent_entropy
arch/Kconfig | 18 +
arch/powerpc/kernel/Makefile | 5 +
block/blk-softirq.c | 2 +-
drivers/char/random.c | 4 +-
fs/namespace.c | 1 +
include/linux/compiler-gcc.h | 7 +
include/linux/compiler.h | 4 +
include/linux/fdtable.h | 2 +-
include/linux/genhd.h | 2 +-
include/linux/init.h | 5 +-
include/linux/random.h | 15 +-
init/main.c | 1 +
kernel/fork.c | 7 +-
kernel/rcu/tiny.c | 2 +-
kernel/rcu/tree.c | 2 +-
kernel/sched/fair.c | 2 +-
kernel/softirq.c | 4 +-
kernel/time/timer.c | 2 +-
lib/irq_poll.c | 2 +-
lib/random32.c | 2 +-
mm/page_alloc.c | 5 +
net/core/dev.c | 4 +-
scripts/Makefile.gcc-plugins | 9 +-
scripts/gcc-plugins/latent_entropy_plugin.c | 640 ++++++++++++++++++++++++++++
24 files changed, 725 insertions(+), 22 deletions(-)
create mode 100644 scripts/gcc-plugins/latent_entropy_plugin.c
--
Kees Cook
Nexus Security
^ permalink raw reply [relevance 87%]
* [GIT PULL] lkdtm fixes for v4.9-rc4
@ 2016-11-01 17:32 92% Kees Cook
0 siblings, 1 reply; 200+ results
From: Kees Cook @ 2016-11-01 17:32 UTC (permalink / raw)
To: gregkh; +Cc: linux-kernel, Catalin Marinas
Hi,
Please pull this lkdtm fix for v4.9-rc4.
Thanks!
-Kees
The following changes since commit 07d9a380680d1c0eb51ef87ff2eab5c994949e69:
Linux 4.9-rc2 (2016-10-23 17:10:14 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/lkdtm-v4.9-rc4
for you to fetch changes up to 45103117d334e939a4f3a128ca3505a24516dfb6:
lkdtm: Do not use flush_icache_range() on user addresses (2016-10-31 09:29:16 -0700)
----------------------------------------------------------------
- fix misuse of icache flushing against userspace memory
----------------------------------------------------------------
Catalin Marinas (1):
lkdtm: Do not use flush_icache_range() on user addresses
drivers/misc/lkdtm_perms.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--
Kees Cook
Nexus Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] gcc-plugin fixes for v4.9-rc4
@ 2016-11-01 17:39 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2016-11-01 17:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Kees Cook
Hi,
Please pull these gcc-plugin fixes for v4.9-rc4.
Thanks!
-Kees
The following changes since commit 07d9a380680d1c0eb51ef87ff2eab5c994949e69:
Linux 4.9-rc2 (2016-10-23 17:10:14 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/gcc-plugins-v4.9-rc4
for you to fetch changes up to 58bea4144d235cee5bb51203b032ddafd6d1cf8d:
latent_entropy: Fix wrong gcc code generation with 64 bit variables (2016-10-31 11:30:41 -0700)
----------------------------------------------------------------
- make sure required exports from gcc plugins are visible to gcc
- switch latent_entropy to unsigned long to avoid stack frame bloat
----------------------------------------------------------------
Kees Cook (2):
gcc-plugins: Export symbols needed by gcc
latent_entropy: Fix wrong gcc code generation with 64 bit variables
mm/page_alloc.c | 2 +-
scripts/gcc-plugins/cyc_complexity_plugin.c | 4 ++--
scripts/gcc-plugins/gcc-common.h | 1 +
scripts/gcc-plugins/latent_entropy_plugin.c | 25 ++++++++++++-------------
scripts/gcc-plugins/sancov_plugin.c | 4 ++--
5 files changed, 18 insertions(+), 18 deletions(-)
--
Kees Cook
Nexus Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] seccomp fixes for v4.9-rc4
@ 2016-11-01 17:46 92% Kees Cook
0 siblings, 1 reply; 200+ results
From: Kees Cook @ 2016-11-01 17:46 UTC (permalink / raw)
To: James Morris
Cc: linux-kernel, Mickaël Salaün, Ricky Zhou,
linux-security-module
Hi,
Please pull these seccomp fixes for v4.9-rc4.
Thanks!
-Kees
The following changes since commit 07d9a380680d1c0eb51ef87ff2eab5c994949e69:
Linux 4.9-rc2 (2016-10-23 17:10:14 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-v4.9-rc4
for you to fetch changes up to d881d25cf5bc2fafbbfb383a475278977e1bd55a:
samples/seccomp: Support programs with >256 instructions (2016-11-01 08:58:17 -0700)
----------------------------------------------------------------
- fix function prototype documentation
- fix samples to include NNP setting
- fix samples to avoid rule truncation
- fix samples hostprogs variable in Makefile
----------------------------------------------------------------
Mickaël Salaün (1):
seccomp: Fix documentation
Ricky Zhou (3):
samples/seccomp: Fix hostprogs variable
samples/seccomp: Enable PR_SET_NO_NEW_PRIVS in dropper
samples/seccomp: Support programs with >256 instructions
kernel/seccomp.c | 7 +++----
samples/seccomp/Makefile | 4 ++--
samples/seccomp/bpf-helper.c | 38 +++++++++++++++++++-------------------
samples/seccomp/dropper.c | 7 +++++--
4 files changed, 29 insertions(+), 27 deletions(-)
--
Kees Cook
Nexus Security
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] lkdtm fixes for v4.9-rc4
@ 2016-11-01 21:22 92% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2016-11-01 21:22 UTC (permalink / raw)
To: Greg KH; +Cc: LKML, Catalin Marinas
On Tue, Nov 1, 2016 at 1:19 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Tue, Nov 01, 2016 at 10:32:03AM -0700, Kees Cook wrote:
>> Hi,
>>
>> Please pull this lkdtm fix for v4.9-rc4.
>>
>> Thanks!
>>
>> -Kees
>>
>> The following changes since commit 07d9a380680d1c0eb51ef87ff2eab5c994949e69:
>>
>> Linux 4.9-rc2 (2016-10-23 17:10:14 -0700)
>>
>> are available in the git repository at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/lkdtm-v4.9-rc4
>
> I get the build error:
> ERROR: "access_process_vm" [drivers/misc/lkdtm.ko] undefined!
> when pulling this into my tree (based on 4.9-rc3) :(
>
> And for just a single patch, a patch in email is easy for me to handle,
> as obviously this didn't go through any 0-day build testing...
Oh, hrm. I will investigate.
-Kees
--
Kees Cook
Nexus Security
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] seccomp fixes for v4.9-rc4
@ 2016-11-02 2:07 92% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2016-11-02 2:07 UTC (permalink / raw)
To: James Morris
Cc: LKML, Mickaël Salaün, Ricky Zhou, linux-security-module
On Tue, Nov 1, 2016 at 4:43 PM, James Morris <jmorris@namei.org> wrote:
> On Tue, 1 Nov 2016, Kees Cook wrote:
>
>> Hi,
>>
>> Please pull these seccomp fixes for v4.9-rc4.
>
>> ----------------------------------------------------------------
>> - fix function prototype documentation
>> - fix samples to include NNP setting
>> - fix samples to avoid rule truncation
>> - fix samples hostprogs variable in Makefile
>>
>> ----------------------------------------------------------------
>
> These fixes don't seem very critical, and Linus was talking yesterday at
> KS about too much churn in the -rc series with non-critical fixes.
>
> How about we queue this up for 4.10?
Okay, sounds good to me. Thanks!
-Kees
--
Kees Cook
Nexus Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] pstore updates for v4.10-rc1
@ 2016-12-07 23:35 84% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2016-12-07 23:35 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Joel Fernandes, Li Pengcheng, Liu Hailong,
Li Zhong, Namhyung Kim, Steven Rostedt
Hi,
As requested, here's an early pull request for v4.10. :) Please pull these
pstore changes for v4.10-rc1.
Thanks!
-Kees
The following changes since commit 07d9a380680d1c0eb51ef87ff2eab5c994949e69:
Linux 4.9-rc2 (2016-10-23 17:10:14 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/pstore-v4.10-rc1
for you to fetch changes up to fc46d4e453f50d2b376267f180cae250b54f9fb4:
ramoops: add pdata NULL check to ramoops_probe (2016-11-15 16:34:32 -0800)
----------------------------------------------------------------
Improvements and fixes to pstore subsystem:
- Add additional checks for bad platform data
- Remove bounce buffer in console writer
- Protect read/unlink race with a mutex
- Correctly give up during dump locking failures
- Increase ftrace bandwidth by splitting ftrace buffers per CPU
----------------------------------------------------------------
Joel Fernandes (8):
pstore: Make spinlock per zone instead of global
pstore: Warn on PSTORE_TYPE_PMSG using deprecated function
pstore: Allow prz to control need for locking
ramoops: Split ftrace buffer space into per-CPU zones
pstore: Add ftrace timestamp counter
pstore: Merge per-CPU ftrace records into one
ftrace: Provide API to use global filtering for ftrace ops
pstore: Use global ftrace filters for function trace filtering
Kees Cook (4):
pstore: Make ramoops_init_przs generic for other prz arrays
pstore: improve error report for failed setup
pstore: Clarify context field przs as dprzs
ramoops: add pdata NULL check to ramoops_probe
Li Pengcheng (1):
pstore: Actually give up during locking failure
Namhyung Kim (2):
pstore: Protect unlink with read_mutex
pstore: Convert console write to use ->write_buf
.../bindings/reserved-memory/ramoops.txt | 3 +
fs/pstore/ftrace.c | 11 +-
fs/pstore/inode.c | 15 +-
fs/pstore/internal.h | 34 ---
fs/pstore/platform.c | 5 +-
fs/pstore/ram.c | 327 ++++++++++++++++-----
fs/pstore/ram_core.c | 27 +-
include/linux/ftrace.h | 2 +
include/linux/pstore.h | 76 +++++
include/linux/pstore_ram.h | 14 +-
kernel/trace/ftrace.c | 17 ++
11 files changed, 404 insertions(+), 127 deletions(-)
--
Kees Cook
Nexus Security
^ permalink raw reply [relevance 84%]
* [GIT PULL] gcc-plugins updates for v4.10-rc1
@ 2016-12-07 23:59 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2016-12-07 23:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Andrew Donnellan
Hi,
Please pull these gcc-plugins changes for v4.10-rc1.
Thanks!
-Kees
The following changes since commit 07d9a380680d1c0eb51ef87ff2eab5c994949e69:
Linux 4.9-rc2 (2016-10-23 17:10:14 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/gcc-plugins-v4.10-rc1
for you to fetch changes up to 215e2aa6c024d27cdbe88e2ea88cb59dcab588eb:
gcc-plugins: Adjust Kconfig to avoid cyc_complexity (2016-11-08 16:27:03 -0800)
----------------------------------------------------------------
Minor changes to the gcc plugins:
- Add the gcc plugins Makefile to MAINTAINERS to route things correctly
- Hide cyc_complexity behind !CONFIG_TEST for the future unhiding of
plugins generally.
----------------------------------------------------------------
Andrew Donnellan (1):
MAINTAINERS: add GCC plugins Makefile
Kees Cook (1):
gcc-plugins: Adjust Kconfig to avoid cyc_complexity
MAINTAINERS | 1 +
arch/Kconfig | 7 ++++++-
2 files changed, 7 insertions(+), 1 deletion(-)
--
Kees Cook
Nexus Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] gcc-plugins updates for v4.10-rc3
@ 2017-01-03 20:14 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-01-03 20:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Arnd Bergmann, Kees Cook
Hi,
Please pull these gcc-plugins changes for v4.10-rc3.
Thanks!
-Kees
The following changes since commit 0c744ea4f77d72b3dcebb7a8f2684633ec79be88:
Linux 4.10-rc2 (2017-01-01 14:31:53 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/gcc-plugins-v4.10-rc3
for you to fetch changes up to 81d873a87114b05dbb74d1fbf0c4322ba4bfdee4:
gcc-plugins: update gcc-common.h for gcc-7 (2017-01-03 12:08:59 -0800)
----------------------------------------------------------------
Small fixes for gcc-plugins when using certain gcc versions:
- Update gcc-common.h for gcc 7 from Emese Revfy.
- Fix latent_entropy type for early gcc on ARM from PaX Team.
----------------------------------------------------------------
Kees Cook (2):
latent_entropy: fix ARM build error on earlier gcc
gcc-plugins: update gcc-common.h for gcc-7
scripts/gcc-plugins/gcc-common.h | 85 +++++++++++++++++++++++++++++
scripts/gcc-plugins/latent_entropy_plugin.c | 4 +-
2 files changed, 87 insertions(+), 2 deletions(-)
--
Kees Cook
Nexus Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] pstore fix for v4.10-rc8
@ 2017-02-09 19:56 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-02-09 19:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Brian Norris, Kees Cook
Hi,
This pstore regression was just noticed. If I'm too late, this can land
in v4.11 and -stable, but if the fix window is still open for v4.10, I'd
love to see this fix pulled for v4.10.
Thanks!
-Kees
The following changes since commit d966564fcdc19e13eb6ba1fbe6b8101070339c3d:
Revert "x86/ioapic: Restore IO-APIC irq_chip retrigger callback" (2017-02-08 18:08:29 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/pstore-v4.10-rc8
for you to fetch changes up to 8672aed7bd865774257efd40929702759a869329:
pstore: don't OOPS when there are no ftrace zones (2017-02-09 11:49:49 -0800)
----------------------------------------------------------------
Fix pstore regression (boot Oops) when ftrace disabled, from Brian Norris.
----------------------------------------------------------------
Brian Norris (1):
pstore: don't OOPS when there are no ftrace zones
fs/pstore/ram.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] pstore updates for v4.11-rc1
@ 2017-02-21 19:52 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-02-21 19:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Brian Norris
Hi,
Please pull these pstore changes for v4.11-rc1.
Thanks!
-Kees
The following changes since commit 7089db84e356562f8ba737c29e472cc42d530dbc:
Linux 4.10-rc8 (2017-02-12 13:03:20 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/pstore-v4.11-rc1
for you to fetch changes up to fc1b326efd276e7d121f5c1ced2884ae52a85814:
MAINTAINERS: Adjust pstore git repo URI, add files (2017-02-13 10:25:52 -0800)
----------------------------------------------------------------
Minor changes to pstore tree:
- update MAINTAINERS with current git repo, add more files.
- move prz allocation checks into the walker
- initialize flags correctly (by accident spinlock was technically ok)
----------------------------------------------------------------
Kees Cook (3):
pstore: Correctly initialize spinlock and flags
pstore: Check for prz allocation in walker
MAINTAINERS: Adjust pstore git repo URI, add files
MAINTAINERS | 7 +++++--
fs/pstore/ram.c | 5 +++--
fs/pstore/ram_core.c | 12 +++++++-----
3 files changed, 15 insertions(+), 9 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] usercopy updates for v4.11-rc1
@ 2017-02-21 20:03 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-02-21 20:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Hoeun Ryu
Hi,
Please pull these usercopy changes for v4.11-rc1.
Thanks!
-Kees
The following changes since commit 0c744ea4f77d72b3dcebb7a8f2684633ec79be88:
Linux 4.10-rc2 (2017-01-01 14:31:53 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/usercopy-v4.11-rc1
for you to fetch changes up to 4c5d7bc63775b40631b75f6c59a3a3005455262d:
usercopy: Add tests for all get_user() sizes (2017-02-21 11:59:38 -0800)
----------------------------------------------------------------
This improves the usercopy tests:
- check zeroing on failed copy_from_user()/get_user() (caught bug on ARM)
- adjust tests for SMAP/PAN (can't zero userspace memory on failure)
----------------------------------------------------------------
Hoeun Ryu (1):
usercopy: add testcases to check zeroing on failure
Kees Cook (2):
usercopy: Adjust tests to deal with SMAP/PAN
usercopy: Add tests for all get_user() sizes
lib/test_user_copy.c | 117 +++++++++++++++++++++++++++++++++++++++++++++------
1 file changed, 103 insertions(+), 14 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] rodata updates for v4.11-rc1
@ 2017-02-21 20:08 83% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-02-21 20:08 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Heiko Carstens, Ingo Molnar, Jessica Yu, Laura Abbott
Hi,
This is a small series that has been living in my KSPP -next tree that I've
extracted separately for v4.11, since there may be some merge clean-up needed
with them. CONFIG_DEBUG_RODATA (and CONFIG_SET_MODULE_RONX) have long been
inaccurate terms for the protection they provide, and this renames them. As
such there may be some fix-ups needs to catch any CONFIG_DEBUG_RODATA cases
added/changed since v4.10-rc2. In the -next merges it has been pretty minor,
so I don't expect much pain, but I wanted to err on the side of caution.
Thanks!
-Kees
The following changes since commit 0c744ea4f77d72b3dcebb7a8f2684633ec79be88:
Linux 4.10-rc2 (2017-01-01 14:31:53 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/rodata-v4.11-rc1
for you to fetch changes up to 0f5bf6d0afe4be6e1391908ff2d6dc9730e91550:
arch: Rename CONFIG_DEBUG_RODATA and CONFIG_DEBUG_MODULE_RONX (2017-02-07 12:32:52 -0800)
----------------------------------------------------------------
This renames the (now inaccurate) CONFIG_DEBUG_RODATA and related config
CONFIG_SET_MODULE_RONX to the more sensible CONFIG_STRICT_KERNEL_RWX and
CONFIG_STRICT_MODULE_RWX.
----------------------------------------------------------------
Laura Abbott (2):
arch: Move CONFIG_DEBUG_RODATA and CONFIG_SET_MODULE_RONX to be common
arch: Rename CONFIG_DEBUG_RODATA and CONFIG_DEBUG_MODULE_RONX
Documentation/DocBook/kgdb.tmpl | 8 +++----
Documentation/security/self-protection.txt | 10 +++++++--
arch/Kconfig | 34 ++++++++++++++++++++++++++++++
arch/arm/Kconfig | 4 ++++
arch/arm/Kconfig.debug | 11 ----------
arch/arm/configs/aspeed_g4_defconfig | 4 ++--
arch/arm/configs/aspeed_g5_defconfig | 4 ++--
arch/arm/include/asm/cacheflush.h | 2 +-
arch/arm/kernel/patch.c | 4 ++--
arch/arm/kernel/vmlinux.lds.S | 8 +++----
arch/arm/mm/Kconfig | 14 +-----------
arch/arm/mm/init.c | 4 ++--
arch/arm64/Kconfig | 5 ++---
arch/arm64/Kconfig.debug | 13 +-----------
arch/arm64/kernel/insn.c | 2 +-
arch/parisc/Kconfig | 1 +
arch/parisc/Kconfig.debug | 11 ----------
arch/parisc/configs/712_defconfig | 1 -
arch/parisc/configs/c3000_defconfig | 1 -
arch/parisc/mm/init.c | 2 +-
arch/s390/Kconfig | 5 ++---
arch/s390/Kconfig.debug | 3 ---
arch/x86/Kconfig | 5 ++---
arch/x86/Kconfig.debug | 11 ----------
include/linux/filter.h | 4 ++--
include/linux/init.h | 4 ++--
include/linux/module.h | 2 +-
init/main.c | 4 ++--
kernel/configs/android-recommended.config | 2 +-
kernel/module.c | 6 +++---
kernel/power/hibernate.c | 2 +-
kernel/power/power.h | 4 ++--
kernel/power/snapshot.c | 4 ++--
33 files changed, 90 insertions(+), 109 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 83%]
* [GIT PULL] gcc-plugins updates for v4.11-rc1
@ 2017-02-21 20:16 79% Kees Cook
0 siblings, 1 reply; 200+ results
From: Kees Cook @ 2017-02-21 20:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Emese Revfy
Hi,
Please pull these gcc-plugins changes for v4.11-rc1. This includes two new
plugins for the upstream kernel: structleak and initify. The structleak
plugin performs forced initialization of certain structures to avoid
possible information exposures to userspace. The initify plugin performs
analysis to find functions and strings that can be marked as __init or
__exit to reduce the runtime size of the kernel.
Thanks!
-Kees
The following changes since commit a121103c922847ba5010819a3f250f1f7fc84ab8:
Linux 4.10-rc3 (2017-01-08 14:18:17 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/gcc-plugins-v4.11-rc1
for you to fetch changes up to 5988b5db7be58878cbbf1f8251968c8b89327d21:
Merge commit 'v4.10-rc3^{}' into for-next/gcc-plugins (2017-02-16 16:32:34 -0800)
----------------------------------------------------------------
Updates to the gcc-plugins:
- infrastructure updates (gcc-common.h)
- introduce structleak plugin for forced initialization of some structures
- introduce initify plugin for optimized __init and __exit markings
----------------------------------------------------------------
Emese Revfy (4):
gcc-plugins: Add the initify gcc plugin
util: Move type casts into is_kernel_rodata
initify: Mark functions with the __nocapture attribute
initify: Mark functions with the __unverified_nocapture attribute
Kees Cook (5):
gcc-plugins: add PASS_INFO and build_const_char_string()
gcc-plugins: consolidate on PASS_INFO macro
gcc-plugins: Add structleak for more stack initialization
Merge branch 'for-next/gcc-plugin/structleak' into for-next/gcc-plugins
Merge commit 'v4.10-rc3^{}' into for-next/gcc-plugins
arch/Kconfig | 62 +
arch/arm/include/asm/string.h | 10 +-
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/string.h | 25 +-
arch/powerpc/include/asm/string.h | 19 +-
arch/x86/Kconfig | 1 +
arch/x86/include/asm/string_32.h | 25 +-
arch/x86/include/asm/string_64.h | 23 +-
arch/x86/kernel/hpet.c | 2 +-
arch/x86/lib/Makefile | 4 +
drivers/acpi/acpica/acutils.h | 2 +-
fs/char_dev.c | 2 +-
fs/ntfs/debug.h | 6 +-
fs/ocfs2/cluster/masklog.h | 2 +-
include/acpi/acpixf.h | 2 +-
include/asm-generic/asm-prototypes.h | 8 +-
include/asm-generic/bug.h | 7 +-
include/asm-generic/vmlinux.lds.h | 2 +
include/drm/drm_drv.h | 2 +-
include/linux/audit.h | 5 +-
include/linux/compiler-gcc.h | 22 +
include/linux/compiler.h | 14 +-
include/linux/fs.h | 8 +-
include/linux/printk.h | 2 +-
include/linux/ratelimit.h | 3 +-
include/linux/string.h | 75 +-
lib/string.c | 3 +-
lib/vsprintf.c | 6 +-
mm/kasan/kasan.c | 2 +
mm/util.c | 10 +-
scripts/Makefile.gcc-plugins | 18 +
scripts/gcc-plugins/cyc_complexity_plugin.c | 6 +-
scripts/gcc-plugins/gcc-common.h | 55 +-
scripts/gcc-plugins/initify_plugin.c | 1865 +++++++++++++++++++++++++++
scripts/gcc-plugins/latent_entropy_plugin.c | 8 +-
scripts/gcc-plugins/sancov_plugin.c | 8 +-
scripts/gcc-plugins/structleak_plugin.c | 246 ++++
security/integrity/integrity.h | 2 +-
38 files changed, 2416 insertions(+), 147 deletions(-)
create mode 100644 scripts/gcc-plugins/initify_plugin.c
create mode 100644 scripts/gcc-plugins/structleak_plugin.c
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 79%]
* Re: [GIT PULL] gcc-plugins updates for v4.11-rc1
@ 2017-02-22 5:07 92% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-02-22 5:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List, Emese Revfy
On Tue, Feb 21, 2017 at 6:34 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Tue, Feb 21, 2017 at 12:16 PM, Kees Cook <keescook@chromium.org> wrote:
>>
>> Please pull these gcc-plugins changes for v4.11-rc1. This includes two new
>> plugins for the upstream kernel: structleak and initify. The structleak
>> plugin performs forced initialization of certain structures to avoid
>> possible information exposures to userspace. The initify plugin performs
>> analysis to find functions and strings that can be marked as __init or
>> __exit to reduce the runtime size of the kernel.
>
> I pulled this, but then looked at the patch, and decided to unpull it.
Hrm, I will send a pull for just the infrastructure and structleak
changes, since those are independent from the initify changes.
> The crazy "__nocapture()" annotations are too ugly to live, and make
> no sense. They are basically random noise to some very core header
> files. And the "__unverified_nocapture()" ones are worse.
Is it the naming, or something else? I tried to document them as
clearly as I could... the initify plugin needs to figure out if a
string is being retained by a function to decide if it can safely be
moved into the .init section.
> I'm not sure how to fix this issue.
I'm open to ideas. :) Initify certainly has more annotations than most
of the pending plugins, but there needs to be a way to mark things for
plugin consumption.
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] gcc-plugins updates for v4.11-rc1 (take 2)
@ 2017-02-22 5:16 89% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-02-22 5:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Kees Cook
Hi,
Please pull these gcc-plugins changes for v4.11-rc1. (This is take 2,
with the initify series removed.) This includes infrastructure updates
and the structleak plugin, which performs forced initialization of certain
structures to avoid possible information exposures to userspace.
Thanks!
-Kees
The following changes since commit a121103c922847ba5010819a3f250f1f7fc84ab8:
Linux 4.10-rc3 (2017-01-08 14:18:17 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/gcc-plugins-v4.11-rc1
for you to fetch changes up to c054ee3bbf69ebcabb1f3218b7faf4b1b37a8eb6:
Merge branch 'for-next/gcc-plugin/structleak' into for-linus/gcc-plugins (2017-02-21 21:12:57 -0800)
----------------------------------------------------------------
Updates to the gcc-plugins:
- infrastructure updates (gcc-common.h)
- introduce structleak plugin for forced initialization of some structures
----------------------------------------------------------------
Kees Cook (5):
gcc-plugins: add PASS_INFO and build_const_char_string()
gcc-plugins: consolidate on PASS_INFO macro
gcc-plugins: Add structleak for more stack initialization
Merge branch 'for-next/gcc-plugin-infrastructure' into for-linus/gcc-plugins
Merge branch 'for-next/gcc-plugin/structleak' into for-linus/gcc-plugins
arch/Kconfig | 22 +++
include/linux/compiler.h | 6 +-
scripts/Makefile.gcc-plugins | 4 +
scripts/gcc-plugins/cyc_complexity_plugin.c | 6 +-
scripts/gcc-plugins/gcc-common.h | 55 +++++--
scripts/gcc-plugins/latent_entropy_plugin.c | 8 +-
scripts/gcc-plugins/sancov_plugin.c | 8 +-
scripts/gcc-plugins/structleak_plugin.c | 246 ++++++++++++++++++++++++++++
8 files changed, 326 insertions(+), 29 deletions(-)
create mode 100644 scripts/gcc-plugins/structleak_plugin.c
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 89%]
* [GIT PULL] usercopy fix for v4.11-rc1
@ 2017-02-23 23:47 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-02-23 23:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Arnd Bergmann, Kees Cook
Hi,
Please pull this usercopy fix for v4.11-rc1. Arnd noticed a corner case.
Thanks!
-Kees
The following changes since commit 4c5d7bc63775b40631b75f6c59a3a3005455262d:
usercopy: Add tests for all get_user() sizes (2017-02-21 11:59:38 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/usercopy-v4.11-rc1.fix
for you to fetch changes up to 4deaa6fd00be2bf408dd06cdf0c40a1b59237879:
usercopy: ARM NOMMU has no 64-bit get_user (2017-02-22 11:24:08 -0800)
----------------------------------------------------------------
Fix for non-MMU ARM testing, from Arnd Bergmann
----------------------------------------------------------------
Arnd Bergmann (1):
usercopy: ARM NOMMU has no 64-bit get_user
lib/test_user_copy.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] gcc-plugins updates for v4.11-rc2
@ 2017-03-09 21:39 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-03-09 21:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Arnd Bergmann
Hi,
Please pull this gcc-plugins fix for v4.11-rc2.
Thanks!
-Kees
The following changes since commit 5a45a4c5c3f5e36a03770deb102ca6ba256ff3d7:
gcc-plugins: consolidate on PASS_INFO macro (2017-01-13 14:20:03 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/gcc-plugins-v4.11-rc2
for you to fetch changes up to dcc235279a52d49023d4f1af7c3ed468a97015ae:
gcc-plugins: fix sancov_plugin for gcc-5 (2017-02-27 14:10:10 -0800)
----------------------------------------------------------------
Fixes a typo in sancov plugin, exposed in earlier compiler versions
----------------------------------------------------------------
Arnd Bergmann (1):
gcc-plugins: fix sancov_plugin for gcc-5
scripts/gcc-plugins/sancov_plugin.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] devmem fix for v4.11-rc7
@ 2017-04-12 18:54 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-04-12 18:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Tommi Rantala
Hi,
Please pull this devmem change for v4.11-rc7. Tommi tested this successfully
and no one appears to have objected to the RFC patch, so here's the fix. :)
Thanks!
-Kees
The following changes since commit b9b3322f13f350587f17f0a76f008830e3a420d3:
Merge branch 'stable-4.11' of git://git.infradead.org/users/pcmoore/audit (2017-04-12 00:02:33 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/devmem-v4.11-rc7
for you to fetch changes up to a4866aa812518ed1a37d8ea0c881dc946409de94:
mm: Tighten x86 /dev/mem with zeroing reads (2017-04-12 11:40:23 -0700)
----------------------------------------------------------------
Fixes /dev/mem to read back zeros for System RAM areas in the 1MB exception
area on x86 to avoid exposing RAM or tripping hardened usercopy.
----------------------------------------------------------------
Kees Cook (1):
mm: Tighten x86 /dev/mem with zeroing reads
arch/x86/mm/init.c | 41 +++++++++++++++++++--------
drivers/char/mem.c | 82 ++++++++++++++++++++++++++++++++++--------------------
2 files changed, 82 insertions(+), 41 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] pstore updates for v4.12-rc1
@ 2017-05-01 18:23 81% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-05-01 18:23 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Ankit Kumar, Bhumika Goyal, Chris Wilson,
Geliang Tang, Kees Cook, Marta Lofstedt, Namhyung Kim
Hi,
Please pull these pstore changes for v4.12-rc1. This has a large internal
refactoring along with several smaller fixes.
Thanks!
-Kees
The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/pstore-v4.12-rc1
for you to fetch changes up to 3a7d2fd16c57a1ef47dc2891171514231c9c7c6e:
pstore: Solve lockdep warning by moving inode locks (2017-04-27 20:35:34 -0700)
----------------------------------------------------------------
- constify compression structures; Bhumika Goyal
- restore powerpc dumping; Ankit Kumar
- fix more bugs in the rarely exercises module unloading logic
- reorganize filesystem locking to fix problems noticed by lockdep
- refactor internal pstore APIs to make development and review easier:
- improve error reporting
- add kernel-doc structure and function comments
- avoid insane argument passing by using a common record structure
----------------------------------------------------------------
Ankit Kumar (1):
pstore: Fix flags to enable dumps on powerpc
Bhumika Goyal (1):
pstore: constify pstore_zbackend structures
Geliang Tang (1):
pstore: Remove unused vmalloc.h in pmsg
Kees Cook (20):
pstore: Use dynamic spinlock initializer
pstore: Shut down worker when unregistering
pstore: Avoid race in module unloading
pstore: Improve register_pstore() error reporting
pstore: Add kernel-doc for struct pstore_info
pstore: Extract common arguments into structure
pstore: Move record decompression to function
pstore: Switch pstore_mkfile to pass record
pstore: Replace arguments for read() API
pstore: Replace arguments for write() API
pstore: Always allocate buffer for decompression
pstore: Pass record contents instead of copying
pstore: Allocate records on heap instead of stack
pstore: Do not duplicate record metadata
pstore: Replace arguments for erase() API
pstore: Replace arguments for write_buf() API
pstore: Replace arguments for write_buf_user() API
pstore: Remove write_buf() callback
pstore: simplify write_user_compat()
pstore: Solve lockdep warning by moving inode locks
arch/powerpc/kernel/nvram_64.c | 89 +++++------
drivers/acpi/apei/erst.c | 64 ++++----
drivers/firmware/efi/efi-pstore.c | 148 ++++++++-----------
fs/pstore/ftrace.c | 11 +-
fs/pstore/inode.c | 147 +++++++++++--------
fs/pstore/internal.h | 8 +-
fs/pstore/platform.c | 301 ++++++++++++++++++++++----------------
fs/pstore/pmsg.c | 12 +-
fs/pstore/ram.c | 130 ++++++++--------
fs/pstore/ram_core.c | 2 +-
include/linux/pstore.h | 156 ++++++++++++++++----
11 files changed, 607 insertions(+), 461 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 81%]
* [GIT PULL] usercopy updates for v4.12-rc1
@ 2017-05-01 18:34 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-05-01 18:34 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, James Morse, Kees Cook, Laura Abbott, Mark Rutland, Sahara
Hi,
Please pull these hardened usercopy updates for v4.12-rc1.
Thanks!
-Kees
The following changes since commit 4495c08e84729385774601b5146d51d9e5849f81:
Linux 4.11-rc2 (2017-03-12 14:47:08 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/usercopy-v4.12-rc1
for you to fetch changes up to 517e1fbeb65f5eade8d14f46ac365db6c75aea9b:
mm/usercopy: Drop extra is_vmalloc_or_module() check (2017-04-05 12:30:18 -0700)
----------------------------------------------------------------
A couple hardened usercopy changes:
- drop now unneeded is_vmalloc_or_module() check; Laura Abbott
- use enum instead of literals for stack frame API; Sahara
----------------------------------------------------------------
Laura Abbott (1):
mm/usercopy: Drop extra is_vmalloc_or_module() check
Sahara (1):
usercopy: Move enum for arch_within_stack_frames()
arch/x86/include/asm/thread_info.h | 13 +++++++------
include/linux/thread_info.h | 12 ++++++++++++
mm/usercopy.c | 19 +------------------
3 files changed, 20 insertions(+), 24 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] pstore update for v4.12-rc2
@ 2017-05-16 18:54 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-05-16 18:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Kees Cook
Hi,
Please pull this pstore fix for v4.12-rc2.
Thanks!
-Kees
The following changes since commit 3a7d2fd16c57a1ef47dc2891171514231c9c7c6e:
pstore: Solve lockdep warning by moving inode locks (2017-04-27 20:35:34 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/pstore-v4.12-rc2
for you to fetch changes up to 6f61dd3aa35179043f1fcdb0965c5d56278ab724:
efi-pstore: Fix read iter after pstore API refactor (2017-05-16 11:46:49 -0700)
----------------------------------------------------------------
- fix bad EFI vars iterator usage
----------------------------------------------------------------
Kees Cook (1):
efi-pstore: Fix read iter after pstore API refactor
drivers/firmware/efi/efi-pstore.c | 12 +++---------
1 file changed, 3 insertions(+), 9 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] pstore fix for v4.12-rc3
@ 2017-05-23 0:01 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-05-23 0:01 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Kees Cook, Marta Lofstedt
Hi,
Please pull this pstore fix for v4.12-rc3. Marta noticed another misbehavior
in EFI pstore, which this fixes. Hopefully this is the last of the v4.12
fixes for pstore!
Thanks,
-Kees
The following changes since commit 6f61dd3aa35179043f1fcdb0965c5d56278ab724:
efi-pstore: Fix read iter after pstore API refactor (2017-05-16 11:46:49 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/pstore-v4.12-rc3
for you to fetch changes up to c10e8031d5b34cde06b039ca2e8af87a33d5ba11:
efi-pstore: Fix write/erase id tracking (2017-05-22 16:53:09 -0700)
----------------------------------------------------------------
More, and hopefully final, fixes after refactor for EFI pstore backend.
----------------------------------------------------------------
Kees Cook (1):
efi-pstore: Fix write/erase id tracking
drivers/firmware/efi/efi-pstore.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] gcc-plugin updates for v4.12-rc4
@ 2017-06-01 20:25 88% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-06-01 20:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Christoph Hellwig, Trond Myklebust
Hi,
Christoph Hellwig recommended that I send these fixes now, rather than
waiting for the v4.13 merge window. These are all initializer and cast
fixes needed for the future randstruct plugin that haven't been picked
up by the respective maintainers. If this is agreeable, please pull these
gcc-plugins updates for v4.12-rc4.
Thanks!
-Kees
The following changes since commit 08332893e37af6ae779367e78e444f8f9571511d:
Linux 4.12-rc2 (2017-05-21 19:30:23 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/gcc-plugins-v4.12-rc4
for you to fetch changes up to 243dd05d39aa14fac2ffde75cc66dee3270896f8:
mtk-vcodec: Use designated initializers (2017-05-28 10:23:02 -0700)
----------------------------------------------------------------
Use designated initializers for mtk-vcodec, powerplay, amdgpu, and sgi-xp.
Use ERR_CAST() to avoid cross-structure cast in ocf2, ntfs, and NFS.
----------------------------------------------------------------
Kees Cook (7):
NFS: Use ERR_CAST() to avoid cross-structure cast
ntfs: Use ERR_CAST() to avoid cross-structure cast
ocfs2: Use ERR_CAST() to avoid cross-structure cast
sgi-xp: Use designated initializers
drm/amdgpu: Use designated initializers
drm/amd/powerplay: Use designated initializers
mtk-vcodec: Use designated initializers
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 10 +++---
.../gpu/drm/amd/powerplay/hwmgr/vega10_thermal.c | 20 ++++++------
.../media/platform/mtk-vcodec/vdec/vdec_h264_if.c | 8 ++---
.../media/platform/mtk-vcodec/vdec/vdec_vp8_if.c | 8 ++---
.../media/platform/mtk-vcodec/vdec/vdec_vp9_if.c | 8 ++---
drivers/misc/sgi-xp/xp.h | 12 +++++++-
drivers/misc/sgi-xp/xp_main.c | 36 +++++-----------------
fs/nfs/namespace.c | 2 +-
fs/ntfs/namei.c | 2 +-
fs/ocfs2/export.c | 2 +-
10 files changed, 48 insertions(+), 60 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 88%]
* [GIT PULL] seccomp updates for next
@ 2017-06-26 17:02 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-06-26 17:02 UTC (permalink / raw)
To: James Morris; +Cc: linux-security-module, linux-kernel
Hi James,
Please pull these seccomp changes for next. These are all tiny changes,
but I got delayed sending them to you. I'd like have these land for v4.13;
I should have sent them for v4.12. :P
Thanks!
-Kees
The following changes since commit 08332893e37af6ae779367e78e444f8f9571511d:
Linux 4.12-rc2 (2017-05-21 19:30:23 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-next
for you to fetch changes up to 0b5fa2290637a3235898d18dc0e7a136783f1bd2:
seccomp: Switch from atomic_t to recount_t (2017-06-26 09:24:00 -0700)
----------------------------------------------------------------
- cleans up some coding style issues
- adjusts selftests to work correctly under Bionic
- switch from atomic_t to refcount_t for usage tracking
----------------------------------------------------------------
Kees Cook (3):
seccomp: Clean up core dump logic
seccomp: Adjust selftests to avoid double-join
seccomp: Switch from atomic_t to recount_t
kernel/seccomp.c | 16 ++++-----
tools/testing/selftests/seccomp/seccomp_bpf.c | 51 ++++++++++++++++++---------
2 files changed, 42 insertions(+), 25 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] pstore updates for v4.13-rc1
@ 2017-07-05 4:29 88% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-07-05 4:29 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Ankit Kumar, Anton Blanchard, Douglas Anderson,
Geliang Tang, Mahesh Salgaonkar
Hi,
Please pull these pstore changes for v4.13-rc1.
Thanks!
-Kees
The following changes since commit 5ed02dbb497422bf225783f46e6eadd237d23d6b:
Linux 4.12-rc3 (2017-05-28 17:20:53 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/pstore-v4.13-rc1
for you to fetch changes up to 0752e4028c003fba1e2b44c4b3cf6a4482e931b6:
powerpc/nvram: use memdup_user (2017-06-27 17:02:50 -0700)
----------------------------------------------------------------
Various fixes and tweaks for the pstore subsystem. Highlights:
- use memdup_user() instead of open-coded copies (Geliang Tang)
- fix record memory leak during initialization (Douglas Anderson)
- avoid confused compressed record warning (Ankit Kumar)
- prepopulate record timestamp and remove redundant logic from backends
----------------------------------------------------------------
Ankit Kumar (1):
pstore: Don't warn if data is uncompressed and type is not PSTORE_TYPE_DMESG
Douglas Anderson (1):
pstore: Fix leaked pstore_record in pstore_get_backend_records()
Geliang Tang (2):
pstore: use memdup_user
powerpc/nvram: use memdup_user
Kees Cook (5):
pstore: Avoid potential infinite loop
efi-pstore: Refactor erase routine
pstore: Create common record initializer
pstore: Populate pstore record->time field
pstore: Fix format string to use %u for record id
arch/powerpc/kernel/nvram_64.c | 14 +++----
drivers/firmware/efi/efi-pstore.c | 87 +++++++++++++++++----------------------
fs/pstore/inode.c | 22 +++++-----
fs/pstore/internal.h | 2 +
fs/pstore/platform.c | 69 ++++++++++++++++++++-----------
fs/pstore/pmsg.c | 10 ++---
fs/pstore/ram.c | 16 +++----
include/linux/pstore.h | 5 ++-
8 files changed, 114 insertions(+), 111 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 88%]
* [GIT PULL] gcc-plugins updates for v4.13-rc1
@ 2017-07-05 5:05 81% Kees Cook
0 siblings, 1 reply; 200+ results
From: Kees Cook @ 2017-07-05 5:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Ard Biesheuvel, Arnd Bergmann, Jean Delvare
Hi,
Please pull these gcc-plugins changes for v4.13-rc1. The big part is
the randstruct plugin infrastructure. This is the first of two expected
pull requests for randstruct since there are dependencies in other
trees that would be easier to merge once those have landed. Notably,
the IPC allocation refactoring in -mm, and many trivial merge conflicts
across several trees when applying the __randomize_layout annotation. As
a result, it seemed like I should send this now since it is relatively
self-contained, and once the rest of the trees have landed, send the
annotation patches. I'm expecting the final phase of randstruct (automatic
struct selection) will land for v4.14, but if its other tree dependencies
actually make it for v4.13, I can send that merge request too.
Thanks!
-Kees
The following changes since commit 6f7da290413ba713f0cdd9ff1a2a9bb129ef4f6c:
Linux 4.12 (2017-07-02 16:07:02 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/gcc-plugins-v4.13-rc1
for you to fetch changes up to d1185a8c5dd21182012e6dd531b00fd72f4d30cb:
Merge branch 'merge/randstruct' into for-next/gcc-plugins (2017-07-04 21:41:31 -0700)
----------------------------------------------------------------
GCC plugin updates:
- typo fix in Kconfig (Jean Delvare)
- randstruct infrastructure
----------------------------------------------------------------
Arnd Bergmann (1):
ARM: Prepare for randomized task_struct
Jean Delvare (1):
Fix English in description of GCC_PLUGIN_STRUCTLEAK
Kees Cook (9):
gcc-plugins: Detail c-common.h location for GCC 4.6
compiler: Add __designated_init annotation
gcc-plugins: Add the randstruct plugin
randstruct: Whitelist struct security_hook_heads cast
randstruct: Whitelist UNIXCB cast
randstruct: Whitelist big_key path struct overloading
randstruct: Whitelist NIU struct page overloading
Merge branch 'for-next/gcc-plugin-infrastructure' into merge/randstruct
Merge branch 'merge/randstruct' into for-next/gcc-plugins
Documentation/dontdiff | 2 +
arch/Kconfig | 41 +-
arch/arm/include/asm/assembler.h | 2 +
arch/arm/kernel/entry-armv.S | 5 +-
arch/arm/mm/proc-macros.S | 10 +-
include/linux/compiler-gcc.h | 13 +
include/linux/compiler.h | 12 +
include/linux/vermagic.h | 9 +-
scripts/Makefile.gcc-plugins | 4 +
scripts/gcc-plugins/.gitignore | 1 +
scripts/gcc-plugins/Makefile | 8 +
scripts/gcc-plugins/gcc-common.h | 12 +
scripts/gcc-plugins/gen-random-seed.sh | 8 +
scripts/gcc-plugins/randomize_layout_plugin.c | 1028 +++++++++++++++++++++++++
14 files changed, 1146 insertions(+), 9 deletions(-)
create mode 100644 scripts/gcc-plugins/.gitignore
create mode 100644 scripts/gcc-plugins/gen-random-seed.sh
create mode 100644 scripts/gcc-plugins/randomize_layout_plugin.c
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 81%]
* Re: [GIT PULL] gcc-plugins updates for v4.13-rc1
@ 2017-07-05 21:49 89% ` Kees Cook
1 sibling, 0 replies; 200+ results
From: Kees Cook @ 2017-07-05 21:49 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, Ard Biesheuvel, Arnd Bergmann, Jean Delvare
On Wed, Jul 5, 2017 at 12:07 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> Hmm. Completely unrelated comment, and this may not be a gcc 'plugin'
> issue as much as a more general gcc question, but I suspect a plugin
> could do it.
>
> For the kernel, we already really ignore some of the more idiotic C
> standard rules that introduce pointless undefined behavior: things
> like the strict aliasing rules are just insane, and the "overflow is
> udnefined" is bad too. So we use
>
> -fno-strict-aliasing
> -fno-strict-overflow
> -fno-delete-null-pointer-checks
>
> to basically say "those optimizations are fundamentally stupid and
> wrong, and only encourage compilers to generate random code that
> doesn't actually match the source code".
>
> And I suspect one other undefined behavior is the one we _try_ to warn
> about, but where the compiler is not always good enough to give valid
> warnings - uninitialized automatic variables.
>
> Maybe we could have gcc just always initialize variables to zero. Not
> just static ones, but the automatic variables too. And maybe it
> wouldn't generate much extra code, since gcc will see the real
> initialization, and the extra hardening against random behavior will
> just go away - so this might be one of those cheap things where we
> just avoid undefined behavior and avoid leaking old stack contents.
>
> Yes, yes, you'd still have the uninitialized variable warning, but
> that doesn't catch the case where you pass a structure pointer to a
> helper that is *supposed* to fill it in, but misses a field or just
> misses padding.
>
> And maybe I'm wrong, and maybe it would generate a lot of really bad
> extra zeroing and wouldn't be acceptable for most people, but I
> *think* this might be one of those things where we might get some
> extra belt and suspenders kind of hardening basically for free..
>
> Comments?
It is, unfortunately, not free. :( There has been a lot of academic
research[1] into finding ways to minimize the impact, but given some
of the Linux maintainers refusing even zeroing of APIs that pass
stack-based structures[2]. Another thing that has been worked on is
porting the stackleak gcc plugin from grsecurity to upstream[3]. This
does effective clearing of the stack, but it takes a more holistic
approach (and for added fun, it does alloca probes too). Like some of
the more comprehensive academic attempts, it sees about a 4% hit (but
it's doing more...)
I'd love to get the stackleak plugin into upstream (and the work is
on-going), but having something try a "lighter" form of this in a gcc
plugin would be interesting to experiment with.
-Kees
[1] e.g. https://www.internetsociety.org/sites/default/files/ndss2017_09-2_Lu_paper.pdf
performs only uninitialized on-stack pointer zeroing, and
http://www.cs.vu.nl/~giuffrida/papers/safeinit-ndss-2017.pdf shows <5%
performance hit with optimization for initializing everything
[2] https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=getsockname&id=a4467f966f0c70fd232388c05798a84276eef1ef
[3] http://openwall.com/lists/kernel-hardening/2017/06/09/14
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 89%]
* Re: [GIT PULL] gcc-plugins updates for v4.13-rc1
@ 2017-07-05 21:52 92% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-07-05 21:52 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linus Torvalds, Ard Biesheuvel, Linux Kernel Mailing List, Jean Delvare
On Wed, Jul 5, 2017 at 2:48 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wed, Jul 5, 2017 at 11:35 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>
>> So the issue I think would be good to fix is perhaps best explained by
>> pseudo-code
>>
>> int testfn(struct somestruct __user *p)
>> {
>> struct somestruct a;
>>
>> initialize_struct(&a);
>> if (copy_to_user(p, &a, sizeof(a)))
>> return -EFAULT;
>> return 0;
>> }
>>
>> which is obviously made-up code, but is not actually entirely unrealistic.
>
> This particular example should be handled by
> scripts/gcc-plugins/structleak_plugin.c, right?
Only if struct somestruct _contains_ a __user pointer. I would love to
see this logic expanded, of course. :)
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* Re: [git pull] vfs.git pile 11
@ 2017-07-06 19:45 96% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-07-06 19:45 UTC (permalink / raw)
To: Al Viro; +Cc: Linus Torvalds, LKML, linux-fsdevel, Andrew Morton
On Thu, Jul 6, 2017 at 2:12 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> iov_iter/uaccess/hardening pile. For one thing, it trims the
> inline part of copy_to_user/copy_from_user to the minimum that *does*
> need to be inlined - object size checks, basically. For another,
> it sanitizes the checks for iov_iter primitives. There are 4 groups
> of checks: access_ok(), might_fault(), object size and KASAN.
> * access_ok() had been verified by whoever had set the iov_iter
> up. However, that has happened in a function far away, so proving that
> there's no path to actual copying bypassing those checks is hard and
> proving that iov_iter has not been buggered in the meanwhile is also
> not pleasant. So we want those redone in actual copyin/copyout.
> * might_fault() is better off consolidated - we know whether
> it needs to be checked as soon as we enter iov_iter primitive and
> observe the iov_iter flavour. No need to wait until the copyin/copyout.
> The call chains are short enough to make sure we won't miss anything -
> in fact, it's more robust that way, since there are cases where we do
> e.g. forced fault-in before getting to copyin/copyout.
> * KASAN checks belong in copyin/copyout - at the same level
> where other iov_iter flavours would've hit them in memcpy().
> * object size checks should apply to *all* iov_iter flavours,
> not just iovec-backed ones.
> There are two groups of primitives - one gets the kernel object
> described as pointer + size (copy_to_iter(), etc.) while another gets
> it as page + offset + size (copy_page_to_iter(), etc.)
> For the first group the checks are best done where we actually
> have a chance to find the object size. In other words, those belong in
> inline wrappers in uio.h, before calling into iov_iter.c. Same kind
> as we have for inlined part of copy_to_user().
> For the second group there is no object to look at - offset in
> page is just a number, it bears no type information. So we do them
> in the common helper called by iov_iter.c primitives of that kind.
> All it currently does is checking that we are not trying to access
> outside of the compound page; eventually we might want to add some
> sanity checks on the page involved.
>
> So the things we need in copyin/copyout part of iov_iter.c
> do not quite match anything in uaccess.h (we want no zeroing, we *do*
> want access_ok() and KASAN and we want no might_fault() or object size
> checks done on that level). OTOH, these needs are simple enough to
> provide a couple of helpers (static in iov_iter.c) doing just what
> we need...
>
> The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6:
>
> Linux 4.12-rc1 (2017-05-13 13:19:49 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git uaccess-work.iov_iter
>
> for you to fetch changes up to ea93a426af164d346a0b4fe0836143bf32177330:
>
> iov_iter: saner checks on copyin/copyout (2017-06-29 22:29:36 -0400)
>
> ----------------------------------------------------------------
> Al Viro (5):
> copy_{from,to}_user(): move kasan checks and might_fault() out-of-line
> copy_{to,from}_user(): consolidate object size checks
We still need to fix the missed-zeroing-on-overflow corner-case:
https://patchwork.kernel.org/patch/9826959/
> iov_iter/hardening: move object size checks to inlined part
+ if (unlikely(!check_copy_size(addr, bytes, false)))
+ return false;
+ else
+ return _copy_from_iter_full(addr, bytes, i);
Can these be rewritten to avoid the double-negative?
> iov_iter: sanity checks for copy to/from page primitives
Nice to see these!
> iov_iter: saner checks on copyin/copyout
+ might_fault();
Should this be might_sleep()? Just from reading the patch it looked
like you were adding might_sleep()s in the other cases.
>
> include/linux/thread_info.h | 27 +++++++++++++
> include/linux/uaccess.h | 44 +++++----------------
> include/linux/uio.h | 58 ++++++++++++++++++++++++---
> lib/iov_iter.c | 96 ++++++++++++++++++++++++++++++++-------------
> lib/usercopy.c | 10 ++++-
> 5 files changed, 167 insertions(+), 68 deletions(-)
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 96%]
* [GIT PULL] gcc-plugins updates for v4.13-rc2
@ 2017-07-17 20:24 69% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-07-17 20:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel
Hi,
Please pull these gcc-plugins changes for v4.13-rc2. Now that IPC and
other trees have landed, it's sensible to pull the manual markings
portion of randstruct. This is the rest of what was staged in -next for
the gcc-plugins, and comes in three patches, largest first:
- mark "easy" structs with __randomize_layout
- mark task_struct with an optional anonymous struct to isolate the
__randomize_layout section
- mark structs to opt _out_ of automated marking (which will come later)
Various (trivial) merge conflicts exist due to additions to structures.
Since there were more than a couple, I thought I'd just send along how
I solved the conflicts when I did the merge to your tree this morning,
if it helps:
diff --cc fs/proc/internal.h
index 18694598bebf,07b16318223f..aa2b89071630
--- a/fs/proc/internal.h
+++ b/fs/proc/internal.h
@@@ -67,10 -67,10 +67,10 @@@ struct proc_inode
struct proc_dir_entry *pde;
struct ctl_table_header *sysctl;
struct ctl_table *sysctl_entry;
- struct list_head sysctl_inodes;
+ struct hlist_node sysctl_inodes;
const struct proc_ns_operations *ns_ops;
struct inode vfs_inode;
- };
+ } __randomize_layout;
/*
* General functions
diff --cc include/linux/fs.h
index 7b5d6816542b,8f28143486c4..6e1fd5d21248
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@@ -295,8 -275,7 +295,8 @@@ struct kiocb
void (*ki_complete)(struct kiocb *iocb, long ret, long ret2);
void *private;
int ki_flags;
+ enum rw_hint ki_hint;
- };
+ } __randomize_layout;
static inline bool is_sync_kiocb(struct kiocb *kiocb)
{
@@@ -403,8 -392,7 +403,8 @@@ struct address_space
gfp_t gfp_mask; /* implicit gfp mask for allocations */
struct list_head private_list; /* ditto */
void *private_data; /* ditto */
+ errseq_t wb_err;
- } __attribute__((aligned(sizeof(long))));
+ } __attribute__((aligned(sizeof(long)))) __randomize_layout;
/*
* On most architectures that alignment is already the case; but
* must be enforced here for CRIS, to let the least significant bit
@@@ -882,8 -868,8 +882,9 @@@ struct file
struct list_head f_tfile_llink;
#endif /* #ifdef CONFIG_EPOLL */
struct address_space *f_mapping;
+ errseq_t f_wb_err;
- } __attribute__((aligned(4))); /* lest something weird decides that 2 is OK */
+ } __randomize_layout
+ __attribute__((aligned(4))); /* lest something weird decides that 2 is OK */
struct file_handle {
__u32 handle_bytes;
diff --cc include/linux/ipc.h
index 5591f055e13f,ea0eb0b5f98c..fadd579d577d
--- a/include/linux/ipc.h
+++ b/include/linux/ipc.h
@@@ -20,9 -20,6 +20,9 @@@ struct kern_ipc_perm
umode_t mode;
unsigned long seq;
void *security;
+
+ struct rcu_head rcu;
+ atomic_t refcount;
- } ____cacheline_aligned_in_smp;
+ } ____cacheline_aligned_in_smp __randomize_layout;
#endif /* _LINUX_IPC_H */
diff --cc include/linux/sem.h
index be5cf2ea14ad,23bcbdfad4a6..de2deb8676bd
--- a/include/linux/sem.h
+++ b/include/linux/sem.h
@@@ -39,9 -21,7 +39,9 @@@ struct sem_array
int sem_nsems; /* no. of semaphores in array */
int complex_count; /* pending complex operations */
unsigned int use_global_lock;/* >0: global lock required */
+
+ struct sem sems[];
- };
+ } __randomize_layout;
#ifdef CONFIG_SYSVIPC
And, FWIW, this continues to pass allmodconfig (normal and patched to
enable gcc-plugins) builds of x86_64, i386, arm64, arm, powerpc, and
s390 for me.
Thanks!
-Kees
The following changes since commit ffa47aa678cfaa9b88e8a26cfb115b4768325121:
ARM: Prepare for randomized task_struct (2017-06-30 12:00:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/gcc-plugins-v4.13-rc2
for you to fetch changes up to 8acdf5055974e49d337d51ac7011449cfd7b7d05:
randstruct: opt-out externally exposed function pointer structs (2017-06-30 12:00:52 -0700)
----------------------------------------------------------------
Now that IPC and other changes have landed, enable manual markings for
randstruct plugin, including the task_struct.
----------------------------------------------------------------
Kees Cook (3):
randstruct: Mark various structs for randomization
task_struct: Allow randomized layout
randstruct: opt-out externally exposed function pointer structs
arch/arm/include/asm/cacheflush.h | 2 +-
arch/x86/include/asm/paravirt_types.h | 16 ++++++++--------
arch/x86/include/asm/processor.h | 2 +-
fs/mount.h | 4 ++--
fs/namei.c | 2 +-
fs/proc/internal.h | 6 +++---
include/linux/binfmts.h | 4 ++--
include/linux/cdev.h | 2 +-
include/linux/compiler-gcc.h | 13 ++++++++++++-
include/linux/compiler.h | 5 +++++
include/linux/cred.h | 4 ++--
include/linux/dcache.h | 2 +-
include/linux/fs.h | 17 +++++++++--------
include/linux/fs_struct.h | 2 +-
include/linux/ipc.h | 2 +-
include/linux/ipc_namespace.h | 2 +-
include/linux/key-type.h | 4 ++--
include/linux/kmod.h | 2 +-
include/linux/kobject.h | 2 +-
include/linux/lsm_hooks.h | 4 ++--
include/linux/mm_types.h | 4 ++--
include/linux/module.h | 4 ++--
include/linux/mount.h | 2 +-
include/linux/msg.h | 2 +-
include/linux/path.h | 2 +-
include/linux/pid_namespace.h | 2 +-
include/linux/proc_ns.h | 2 +-
include/linux/sched.h | 16 +++++++++++++++-
include/linux/sched/signal.h | 2 +-
include/linux/sem.h | 2 +-
include/linux/shm.h | 2 +-
include/linux/sysctl.h | 2 +-
include/linux/tty.h | 2 +-
include/linux/tty_driver.h | 4 ++--
include/linux/user_namespace.h | 2 +-
include/linux/utsname.h | 2 +-
include/net/af_unix.h | 2 +-
include/net/neighbour.h | 2 +-
include/net/net_namespace.h | 2 +-
include/net/sock.h | 2 +-
kernel/futex.c | 4 ++--
security/keys/internal.h | 2 +-
42 files changed, 97 insertions(+), 66 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 69%]
* [GIT PULL] lkdtm updates for next
@ 2017-08-02 18:58 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-08-02 18:58 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-kernel
Hi Greg,
Please pull these lkdtm changes into your drivers/misc tree for -next.
Thanks!
-Kees
The following changes since commit 520eccdfe187591a51ea9ab4c1a024ae4d0f68d9:
Linux 4.13-rc2 (2017-07-23 16:15:17 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/lkdtm-next
for you to fetch changes up to c7fea48876773603721f545f8c1a2f894291ef85:
lkdtm: Provide timing tests for atomic_t vs refcount_t (2017-07-26 14:38:04 -0700)
----------------------------------------------------------------
improvements for refcount protections
----------------------------------------------------------------
Kees Cook (2):
lkdtm: Provide more complete coverage for REFCOUNT tests
lkdtm: Provide timing tests for atomic_t vs refcount_t
drivers/misc/Makefile | 1 +
drivers/misc/lkdtm.h | 27 ++-
drivers/misc/lkdtm_bugs.c | 83 ---------
drivers/misc/lkdtm_core.c | 25 ++-
drivers/misc/lkdtm_refcount.c | 400 ++++++++++++++++++++++++++++++++++++++++++
5 files changed, 441 insertions(+), 95 deletions(-)
create mode 100644 drivers/misc/lkdtm_refcount.c
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] lkdtm updates for next, part 2
@ 2017-08-15 19:43 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-08-15 19:43 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-kernel
Hi Greg,
Please pull these additional lkdtm changes for next.
Thanks!
-Kees
The following changes since commit c7fea48876773603721f545f8c1a2f894291ef85:
lkdtm: Provide timing tests for atomic_t vs refcount_t (2017-07-26 14:38:04 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/lkdtm-next-part2
for you to fetch changes up to 93e78c6b14c42abe4018c815aeea2aa491522fae:
lkdtm: Add -fstack-protector-strong test (2017-08-15 12:27:35 -0700)
----------------------------------------------------------------
- Add new CORRUPT_STACK_STRONG to test -fstack-protector-strong, since
the existing CORRUPT_STACK test only tested regular -fstack-protector.
- Add pair of tests for checking kernel stack leading/trailing guard pages
under VMAP_STACK: STACK_GUARD_PAGE_LEADING and STACK_GUARD_PAGE_TRAILING.
----------------------------------------------------------------
Kees Cook (2):
lkdtm: Test VMAP_STACK allocates leading/trailing guard pages
lkdtm: Add -fstack-protector-strong test
drivers/misc/lkdtm.h | 3 +++
drivers/misc/lkdtm_bugs.c | 51 ++++++++++++++++++++++++++++++++++++++++++++---
drivers/misc/lkdtm_core.c | 3 +++
3 files changed, 54 insertions(+), 3 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] seccomp updates for next
@ 2017-08-15 22:03 86% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-08-15 22:03 UTC (permalink / raw)
To: James Morris
Cc: linux-kernel, Andy Lutomirski, Tyler Hicks, linux-security-module
Hi James,
Please pull these seccomp changes for next.
Thanks!
-Kees
The following changes since commit 520eccdfe187591a51ea9ab4c1a024ae4d0f68d9:
Linux 4.13-rc2 (2017-07-23 16:15:17 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-next
for you to fetch changes up to f3e1821d9e1cc3fb434d7763001791dcd6720c90:
selftests/seccomp: Test thread vs process killing (2017-08-14 13:46:50 -0700)
----------------------------------------------------------------
Major additions:
- sysctl and seccomp operation to discover available actions. (tyhicks)
- new per-filter configurable logging infrastructure and sysctl. (tyhicks)
- SECCOMP_RET_LOG to log allowed syscalls. (tyhicks)
- SECCOMP_RET_KILL_PROCESS as the new strictest possible action.
- self-tests for new behaviors.
----------------------------------------------------------------
Kees Cook (8):
selftests/seccomp: Add tests for basic ptrace actions
selftests/seccomp: Add simple seccomp overhead benchmark
selftests/seccomp: Refactor RET_ERRNO tests
seccomp: Provide matching filter for introspection
seccomp: Rename SECCOMP_RET_KILL to SECCOMP_RET_KILL_THREAD
seccomp: Introduce SECCOMP_RET_KILL_PROCESS
seccomp: Implement SECCOMP_RET_KILL_PROCESS action
selftests/seccomp: Test thread vs process killing
Tyler Hicks (6):
seccomp: Sysctl to display available actions
seccomp: Operation for checking if an action is available
seccomp: Sysctl to configure actions that are allowed to be logged
seccomp: Selftest for detection of filter flag support
seccomp: Filter flag to log all actions except SECCOMP_RET_ALLOW
seccomp: Action to log before allowing
Documentation/networking/filter.txt | 2 +-
Documentation/sysctl/kernel.txt | 1 +
Documentation/userspace-api/seccomp_filter.rst | 52 +-
include/linux/audit.h | 6 +-
include/linux/seccomp.h | 3 +-
include/uapi/linux/seccomp.h | 23 +-
kernel/seccomp.c | 321 ++++++++++-
samples/seccomp/bpf-direct.c | 4 +-
samples/seccomp/bpf-helper.h | 2 +-
tools/testing/selftests/seccomp/Makefile | 18 +-
.../testing/selftests/seccomp/seccomp_benchmark.c | 99 ++++
tools/testing/selftests/seccomp/seccomp_bpf.c | 610 +++++++++++++++++----
12 files changed, 1009 insertions(+), 132 deletions(-)
create mode 100644 tools/testing/selftests/seccomp/seccomp_benchmark.c
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 86%]
* [GIT PULL] pstore updates for v4.14-rc1
@ 2017-09-05 19:51 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-09-05 19:51 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Kees Cook, Nick Kralevich, Petr Mladek, Sergey Senozhatsky
Hi,
Please pull these pstore changes for v4.14-rc1. Not much happening in
pstore for this release. One change to permission management, noted below.
Thanks!
-Kees
The following changes since commit 520eccdfe187591a51ea9ab4c1a024ae4d0f68d9:
Linux 4.13-rc2 (2017-07-23 16:15:17 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/pstore-v4.14-rc1
for you to fetch changes up to c71b02e4d207cbcf097f9746d5f7967b22905e70:
Revert "pstore: Honor dmesg_restrict sysctl on dmesg dumps" (2017-08-17 16:29:19 -0700)
----------------------------------------------------------------
Make pstore permissions more versatile by removing CAP_SYSLOG requirement
and defining more restrictive root directory DAC permissions default
(0750, which can be adjust after boot unlike the CAP_SYSLOG check).
Suggested by Nick Kralevich.
----------------------------------------------------------------
Kees Cook (2):
pstore: Make default pstorefs root dir perms 0750
Revert "pstore: Honor dmesg_restrict sysctl on dmesg dumps"
fs/pstore/inode.c | 24 +-----------------------
include/linux/syslog.h | 9 ---------
kernel/printk/printk.c | 3 +--
3 files changed, 2 insertions(+), 34 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] gcc-plugins updates for v4.14-rc1
@ 2017-09-05 20:02 88% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-09-05 20:02 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Alex Deucher, Ard Biesheuvel, David S. Miller, Kees Cook
Hi,
Please pull these gcc-plugins changes for v4.14-rc1. This finishes the
porting work on randstruct, and introduces a new option to structleak,
both noted below.
Thanks!
-Kees
The following changes since commit 520eccdfe187591a51ea9ab4c1a024ae4d0f68d9:
Linux 4.13-rc2 (2017-07-23 16:15:17 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/gcc-plugins-v4.14-rc1
for you to fetch changes up to ad05e6ca7b5fcf15ff178da662035ec7718f938c:
Merge branch 'for-next/gcc-plugin/structleak' into for-next/gcc-plugins (2017-08-07 13:29:04 -0700)
----------------------------------------------------------------
- For the randstruct plugin, enable automatic randomization of structures
that are entirely function pointers (along with a couple designated
initializer fixes).
- For the structleak plugin, provide an option to perform zeroing
initialization of all otherwise uninitialized stack variables that are
passed by reference (Ard Biesheuvel).
----------------------------------------------------------------
Ard Biesheuvel (1):
gcc-plugins: structleak: add option to init all vars used as byref args
Kees Cook (4):
drm/amd/powerplay: rv: Use designated initializers
drivers/net/wan/z85230.c: Use designated initializers
randstruct: Enable function pointer struct detection
Merge branch 'for-next/gcc-plugin/structleak' into for-next/gcc-plugins
arch/Kconfig | 19 +++++++++++-----
drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c | 8 +++----
drivers/net/wan/z85230.c | 30 ++++++++++++--------------
scripts/Makefile.gcc-plugins | 1 +
scripts/gcc-plugins/randomize_layout_plugin.c | 3 ---
scripts/gcc-plugins/structleak_plugin.c | 13 +++++++++--
6 files changed, 44 insertions(+), 30 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 88%]
* [GIT PULL] secureexec update for v4.14-rc1
@ 2017-09-05 20:11 83% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-09-05 20:11 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Andy Lutomirski, Casey Schaufler,
Eric W. Biederman, James Morris, John Johansen, Kees Cook,
Paul Moore, Serge Hallyn
Hi,
Please pull these secureexec changes for v4.14-rc1. Notes on the series
below.
Thanks!
-Kees
The following changes since commit 520eccdfe187591a51ea9ab4c1a024ae4d0f68d9:
Linux 4.13-rc2 (2017-07-23 16:15:17 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/secureexec-v4.14-rc1
for you to fetch changes up to fe8993b3a05cbba6318a54e0f85901aaea6fc244:
exec: Consolidate pdeath_signal clearing (2017-08-01 12:03:14 -0700)
----------------------------------------------------------------
This series has the ultimate goal of providing a sane stack rlimit when
running set*id processes. To do this, the bprm_secureexec LSM hook is
collapsed into the bprm_set_creds hook so the secureexec-ness of an exec
can be determined early enough to make decisions about rlimits and the
resulting memory layouts. Other logic acting on the secureexec-ness of an
exec is similarly consolidated. Capabilities needed some special handling,
but the refactoring removed other special handling, so that was a wash.
----------------------------------------------------------------
Kees Cook (15):
exec: Rename bprm->cred_prepared to called_set_creds
exec: Correct comments about "point of no return"
binfmt: Introduce secureexec flag
apparmor: Refactor to remove bprm_secureexec hook
selinux: Refactor to remove bprm_secureexec hook
smack: Refactor to remove bprm_secureexec hook
commoncap: Refactor to remove bprm_secureexec hook
commoncap: Move cap_elevated calculation into bprm_set_creds
LSM: drop bprm_secureexec hook
exec: Use secureexec for setting dumpability
exec: Use secureexec for clearing pdeath_signal
smack: Remove redundant pdeath_signal clearing
exec: Consolidate dumpability logic
exec: Use sane stack rlimit under secureexec
exec: Consolidate pdeath_signal clearing
fs/binfmt_elf.c | 2 +-
fs/binfmt_elf_fdpic.c | 2 +-
fs/binfmt_flat.c | 2 +-
fs/exec.c | 56 ++++++++++++++++++++++++++++----------
include/linux/binfmts.h | 24 ++++++++++++----
include/linux/lsm_hooks.h | 14 ++++------
include/linux/security.h | 7 -----
security/apparmor/domain.c | 21 ++------------
security/apparmor/include/domain.h | 1 -
security/apparmor/include/file.h | 3 --
security/apparmor/lsm.c | 1 -
security/commoncap.c | 50 ++++++++--------------------------
security/security.c | 5 ----
security/selinux/hooks.c | 26 ++++--------------
security/smack/smack_lsm.c | 34 ++---------------------
security/tomoyo/tomoyo.c | 2 +-
16 files changed, 91 insertions(+), 159 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 83%]
* Re: [GIT PULL] Security subsystem updates for 4.14
@ 2017-09-14 21:09 92% ` Kees Cook
0 siblings, 1 reply; 200+ results
From: Kees Cook @ 2017-09-14 21:09 UTC (permalink / raw)
To: James Morris
Cc: Paul Moore, Linus Torvalds, LSM List, Christoph Hellwig,
Linux Kernel Mailing List, Mimi Zohar
On Sat, Sep 9, 2017 at 9:32 PM, James Morris <jmorris@namei.org> wrote:
> On Fri, 8 Sep 2017, Paul Moore wrote:
>
>> > This is also why I tend to prefer getting multiple branches for
>> > independent things.
>
> [...]
>
>>
>> Is it time to start sending pull request for each LSM and thing under
>> security/ directly? I'm not sure I have a strong preference either
>> way, I just don't want to see the SELinux changes ignored during the
>> merge window.
>
> They won't be ignored, we just need to get this issue resolved now and
> figure out how to implement multiple branches in the security tree.
>
> Looking at other git repos, the x86 folk have multiple branches.
Yeah, the x86 approach is what inspired my tree layout.
> One option for me would be to publish the trees I pull from as branches
> along side mine, with 'next' being a merge of all of directly applied
> patchsets and those ready for Linus to pull as one.
>
> So, branches in
> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security
>
> might be:
>
> next-selinux (Paul's next branch)
> next-apparmor (JJ's next branch)
> next-integrity (Mimi's)
> next-tpm (Jarkko's)
> [etc.]
>
> next (merge all of the above to here)
>
> That way, we have a coherent 'next' branch for people to develop against
> and to push to Linus, but he can pull individual branches feeding into it
> if something is broken in one of them.
>
> Does that sound useful?
This is what I do with the KSPP tree (since it has a few unrelated
things in it), but you run the risk of getting too fine-grain and
creating dependencies between trees (e.g. adding a new hook that two
LSMs implement means either they depend on each other or both depend
on some third "core" tree).
How separable are the patches, normally?
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] Security subsystem updates for 4.14
@ 2017-09-14 21:25 92% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-09-14 21:25 UTC (permalink / raw)
To: James Morris
Cc: Paul Moore, Linus Torvalds, LSM List, Christoph Hellwig,
Linux Kernel Mailing List, Mimi Zohar
On Thu, Sep 14, 2017 at 2:13 PM, James Morris <jmorris@namei.org> wrote:
> On Thu, 14 Sep 2017, Kees Cook wrote:
>
>> How separable are the patches, normally?
>
> They're usually mostly separate, but may depend on some core LSM change,
> or similar.
>
> Casey has mentioned off-list that it is useful to have a coherent up to
> date security branch to work against when making core LSM changes.
Yeah, for sure. This "merge all topics" tree is what I have for KSPP
(and it's what I hand to -next).
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] seccomp updates for v4.14-rc2
@ 2017-09-22 18:34 85% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-09-22 18:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Andy Lutomirski, Kees Cook, Tyler Hicks
Hi,
This is a direct seccomp pull request (similar to SELinux's for the v4.14
window); it's the same series that I sent to James earlier (notes below).
Please pull these seccomp changes for v4.14-rc2.
Thanks!
-Kees
The following changes since commit 520eccdfe187591a51ea9ab4c1a024ae4d0f68d9:
Linux 4.13-rc2 (2017-07-23 16:15:17 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-v4.14-rc2
for you to fetch changes up to 6849243bf4c6155151b294e9f0e0dc9540d6f083:
samples: Unrename SECCOMP_RET_KILL (2017-08-16 20:26:57 -0700)
----------------------------------------------------------------
Major additions:
- sysctl and seccomp operation to discover available actions. (tyhicks)
- new per-filter configurable logging infrastructure and sysctl. (tyhicks)
- SECCOMP_RET_LOG to log allowed syscalls. (tyhicks)
- SECCOMP_RET_KILL_PROCESS as the new strictest possible action.
- self-tests for new behaviors.
----------------------------------------------------------------
Kees Cook (9):
selftests/seccomp: Add tests for basic ptrace actions
selftests/seccomp: Add simple seccomp overhead benchmark
selftests/seccomp: Refactor RET_ERRNO tests
seccomp: Provide matching filter for introspection
seccomp: Rename SECCOMP_RET_KILL to SECCOMP_RET_KILL_THREAD
seccomp: Introduce SECCOMP_RET_KILL_PROCESS
seccomp: Implement SECCOMP_RET_KILL_PROCESS action
selftests/seccomp: Test thread vs process killing
samples: Unrename SECCOMP_RET_KILL
Tyler Hicks (6):
seccomp: Sysctl to display available actions
seccomp: Operation for checking if an action is available
seccomp: Sysctl to configure actions that are allowed to be logged
seccomp: Selftest for detection of filter flag support
seccomp: Filter flag to log all actions except SECCOMP_RET_ALLOW
seccomp: Action to log before allowing
Documentation/networking/filter.txt | 2 +-
Documentation/sysctl/kernel.txt | 1 +
Documentation/userspace-api/seccomp_filter.rst | 52 +-
include/linux/audit.h | 6 +-
include/linux/seccomp.h | 3 +-
include/uapi/linux/seccomp.h | 23 +-
kernel/seccomp.c | 321 ++++++++++-
tools/testing/selftests/seccomp/Makefile | 18 +-
.../testing/selftests/seccomp/seccomp_benchmark.c | 99 ++++
tools/testing/selftests/seccomp/seccomp_bpf.c | 610 +++++++++++++++++----
10 files changed, 1006 insertions(+), 129 deletions(-)
create mode 100644 tools/testing/selftests/seccomp/seccomp_benchmark.c
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 85%]
* [GIT PULL] x86-refcount fix for v4.14-rc3
@ 2017-09-27 10:29 92% Kees Cook
0 siblings, 1 reply; 200+ results
From: Kees Cook @ 2017-09-27 10:29 UTC (permalink / raw)
To: Ingo Molnar; +Cc: linux-kernel, Kees Cook, Mike Galbraith
Hi,
Please pull this x86-refcount fix for v4.14-rc3. This restores the x86
fast-refcount protection after fixing a corner case that was found late
before the merge window opened. This was the only problem seen during
the protection's life in linux-next, so getting this into v4.14 is
highly desired.
Thanks!
-Kees
The following changes since commit e19b205be43d11bff638cad4487008c48d21c103:
Linux 4.14-rc2 (2017-09-24 16:38:56 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/x86-refcount-v4.14-rc3
for you to fetch changes up to 635fee8f6b725a99f511b8e0eca82c3214b9c678:
locking/refcounts, x86/asm: Enable CONFIG_ARCH_HAS_REFCOUNT (2017-09-27 03:05:13 -0700)
----------------------------------------------------------------
Fix x86 fast-refcount protection to avoid corner-case of being used a
function living in the .text.unlikely section.
----------------------------------------------------------------
Kees Cook (2):
locking/refcounts, x86/asm: Use unique .text section for refcount exceptions
locking/refcounts, x86/asm: Enable CONFIG_ARCH_HAS_REFCOUNT
arch/x86/Kconfig | 2 +-
arch/x86/include/asm/refcount.h | 2 +-
arch/x86/mm/extable.c | 7 ++++++-
include/asm-generic/vmlinux.lds.h | 1 +
4 files changed, 9 insertions(+), 3 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] x86-refcount fix for v4.14-rc3
@ 2017-09-27 11:47 92% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-09-27 11:47 UTC (permalink / raw)
To: Ingo Molnar
Cc: LKML, Mike Galbraith, Thomas Gleixner, Peter Zijlstra, H. Peter Anvin
On Wed, Sep 27, 2017 at 12:57 PM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Kees Cook <keescook@chromium.org> wrote:
>
>> Hi,
>>
>> Please pull this x86-refcount fix for v4.14-rc3. This restores the x86
>> fast-refcount protection after fixing a corner case that was found late
>> before the merge window opened. This was the only problem seen during
>> the protection's life in linux-next, so getting this into v4.14 is
>> highly desired.
>
> No, this is clearly v4.15 material.
Given the long bake time in linux-next (with only the one bug), and
that the fix was done weeks ago, why the delay?
>> Kees Cook (2):
>> locking/refcounts, x86/asm: Use unique .text section for refcount exceptions
>> locking/refcounts, x86/asm: Enable CONFIG_ARCH_HAS_REFCOUNT
>
> Do these commits differ from what you sent as patches on Sep 2?
They are the same, but now that we've reached -rc2, there's no longer
the fuzz against the linker script changes, so it seemed like a better
way to send them your way.
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] seccomp fix for v4.14-rc3
@ 2017-09-28 5:57 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-09-28 5:57 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Chris Salls, Kees Cook, Oleg Nesterov, Tycho Andersen
Hi,
Please pull this seccomp fix for v4.14-rc3. Bug was introduced in v4.4,
and went unnoticed until now.
Thanks!
-Kees
The following changes since commit e19b205be43d11bff638cad4487008c48d21c103:
Linux 4.14-rc2 (2017-09-24 16:38:56 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-v4.14-rc3
for you to fetch changes up to 66a733ea6b611aecf0119514d2dddab5f9d6c01e:
seccomp: fix the usage of get/put_seccomp_filter() in seccomp_get_filter() (2017-09-27 22:51:12 -0700)
----------------------------------------------------------------
Fix refcounting bug in CRIU interface, noticed by Chris Salls (Oleg & Tycho).
----------------------------------------------------------------
Oleg Nesterov (1):
seccomp: fix the usage of get/put_seccomp_filter() in seccomp_get_filter()
kernel/seccomp.c | 23 ++++++++++++++++-------
1 file changed, 16 insertions(+), 7 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] lkdtm updates for -next
@ 2017-10-06 15:31 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-10-06 15:31 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-kernel, Kees Cook
Hi,
Please pull these couple lkdtm changes for -next.
Thanks!
-Kees
The following changes since commit e19b205be43d11bff638cad4487008c48d21c103:
Linux 4.14-rc2 (2017-09-24 16:38:56 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/lkdtm-next
for you to fetch changes up to ada7bc9b897124dc2c3a45f9896a48b3eb571f11:
lkdtm: Constify the crashtypes table (2017-10-06 08:12:43 -0700)
----------------------------------------------------------------
- Replace jprobes usage with kprobes
- Constify crashtypes table, add missing static markings
----------------------------------------------------------------
Kees Cook (2):
lkdtm: Convert from jprobe to kprobe
lkdtm: Constify the crashtypes table
drivers/misc/lkdtm_core.c | 164 +++++++++++++---------------------------------
1 file changed, 47 insertions(+), 117 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] lkdtm updates for -next (take 2)
@ 2017-10-06 20:20 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-10-06 20:20 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-kernel, Kees Cook, Masami Hiramatsu
Hi,
Please pull these couple lkdtm changes for -next. This includes fixes for
issues 0-day noticed, for which I've updated my test environment to cover
in the future. (This is also based on -rc3 because arm64 builds are broken
in -rc2.)
Thanks!
-Kees
The following changes since commit 9e66317d3c92ddaab330c125dfe9d06eee268aff:
Linux 4.14-rc3 (2017-10-01 14:54:54 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/lkdtm-next
for you to fetch changes up to 0f743ba9160f320513450a83c670bc70c695db0a:
lkdtm: Constify the crashtypes table (2017-10-06 12:53:19 -0700)
----------------------------------------------------------------
- Replace jprobes usage with kprobes
- Constify crashtypes table, add missing static markings
----------------------------------------------------------------
Kees Cook (2):
lkdtm: Convert from jprobe to kprobe
lkdtm: Constify the crashtypes table
drivers/misc/lkdtm_core.c | 172 +++++++++++++++-------------------------------
1 file changed, 54 insertions(+), 118 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] seccomp fix for v4.14-rc5
@ 2017-10-10 18:50 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-10-10 18:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Colin Ian King
Hi,
Please pull this minor seccomp fix for v4.14-rc5. I debated sending this
at all for v4.14, but since it fixes a minor issue in the prior fix, which
also went to -stable, it seemed better to just get all of it cleaned up
right now.
Thanks!
-Kees
The following changes since commit 66a733ea6b611aecf0119514d2dddab5f9d6c01e:
seccomp: fix the usage of get/put_seccomp_filter() in seccomp_get_filter() (2017-09-27 22:51:12 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-v4.14-rc5
for you to fetch changes up to 084f5601c357e4ee59cf0712200d3f5c4710ba40:
seccomp: make function __get_seccomp_filter static (2017-10-10 11:45:29 -0700)
----------------------------------------------------------------
- fix missed "static" to avoid Sparse warning (Colin King).
----------------------------------------------------------------
Colin Ian King (1):
seccomp: make function __get_seccomp_filter static
kernel/seccomp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] timers-conversion updates for next
@ 2017-10-27 9:36 85% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-10-27 9:36 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: linux-kernel, Martin K. Petersen
Hi Thomas,
Please pull these timer conversions for tip/timers/core. These are the
first batch that Martin asked us to carry in the timers tree.
Thanks!
-Kees
The following changes since commit 52f737c2da40259ac9962170ce608b6fb1b55ee4:
timer: Provide wrappers safe for use with LOCKDEP (2017-10-20 11:07:46 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/timers-conversion-next
for you to fetch changes up to 74a0f5739292a636d337ad6f8d7cd0061636e0eb:
scsi: smartpqi: Convert timers to use timer_setup() (2017-10-27 02:22:00 -0700)
----------------------------------------------------------------
First batch of scsi conversions that have been Reviewed or Acked.
----------------------------------------------------------------
Kees Cook (10):
scsi: aic94xx: Convert timers to use timer_setup()
scsi: be2iscsi: Convert timers to use timer_setup()
scsi: bnx2i: Convert timers to use timer_setup()
scsi: dc395x: Convert timers to use timer_setup()
scsi: fcoe: Convert timers to use timer_setup()
scsi: gdth: Convert timers to use timer_setup()
scsi: isci: Convert timers to use timer_setup()
scsi: libfc: Convert timers to use timer_setup()
scsi: libiscsi: Convert timers to use timer_setup()
scsi: smartpqi: Convert timers to use timer_setup()
drivers/scsi/aic94xx/aic94xx_hwi.c | 3 +--
drivers/scsi/aic94xx/aic94xx_hwi.h | 5 ++---
drivers/scsi/aic94xx/aic94xx_scb.c | 6 +++---
drivers/scsi/aic94xx/aic94xx_tmf.c | 13 ++++++-------
drivers/scsi/be2iscsi/be_main.c | 18 +++++++-----------
drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 11 +++++------
drivers/scsi/bnx2i/bnx2i.h | 2 +-
drivers/scsi/bnx2i/bnx2i_hwi.c | 4 ++--
drivers/scsi/bnx2i/bnx2i_iscsi.c | 15 ++++-----------
drivers/scsi/dc395x.c | 13 +++++--------
drivers/scsi/fcoe/fcoe.c | 2 +-
drivers/scsi/fcoe/fcoe_transport.c | 6 ++++--
drivers/scsi/gdth.c | 6 ++----
drivers/scsi/isci/host.c | 12 ++++++------
drivers/scsi/isci/isci.h | 6 ++----
drivers/scsi/isci/phy.c | 4 ++--
drivers/scsi/isci/port.c | 4 ++--
drivers/scsi/isci/port_config.c | 8 ++++----
drivers/scsi/libfc/fc_fcp.c | 21 ++++++++++-----------
drivers/scsi/libiscsi.c | 16 ++++++----------
drivers/scsi/smartpqi/smartpqi_init.c | 9 ++++-----
include/scsi/libfcoe.h | 2 +-
22 files changed, 80 insertions(+), 106 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 85%]
* [GIT PULL] timers-conversion updates for next (part2)
@ 2017-11-01 19:05 71% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-11-01 19:05 UTC (permalink / raw)
To: Thomas Gleixner
Cc: linux-kernel, Bart Van Assche, Borislav Petkov, Daniel Vetter,
Greg Kroah-Hartman, Martin K. Petersen
Hi Thomas,
Please pull these timer conversions for tip/timers/core. These are the
second batch of scsi conversions along with other conversions that
depend on the timer_setup_on_stack() API, which got added late.
There is at least one more scsi conversion coming, and probably a lot
of other misc conversions. My minimum goal for the merge window for is to
entirely eliminate open-coded setting of the .data field. If possible, I
hope to get rid of init_*timer() entirely, and there is an outside chance
that we can drop setup_*timer() too. We'll see what the merge window looks
like...
Thanks!
-Kees
The following changes since commit 00ed87da35e88a7a4d7f41673beab52ef828f12b:
timer: Add parenthesis around timer_setup() macro arguments (2017-11-01 19:05:05 +0100)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/timers-conversion-next2
for you to fetch changes up to 856ec53fcab37f52b184b0b2e3757702005455ff:
drm: gma500: Convert timers to use timer_setup() (2017-11-01 11:44:52 -0700)
----------------------------------------------------------------
Second batch of scsi conversions that have been Reviewed and/or Acked.
Various *_on_stack() changes for USB, Acked by Greg.
DRM conversion that was declared too late for drm's tree, but Acked for timers.
RAS driver conversion, Acked.
----------------------------------------------------------------
Bart Van Assche (1):
target/iscsi: Simplify timer manipulation code
Kees Cook (14):
scsi: aic7xxx: Convert timers to use timer_setup()
scsi: csiostor: Convert timers to use timer_setup()
scsi: cxgbi: Convert timers to use timer_setup()
scsi: ibmvscsi: Convert timers to use timer_setup()
scsi: ipr: Convert timers to use timer_setup()
scsi: lpfc: Convert timers to use timer_setup()
scsi: megaraid: Convert timers to use timer_setup()
scsi: pmcraid: Convert timers to use timer_setup()
scsi: sas: Convert timers to use timer_setup()
scsi: qla4xxx: Convert timers to use timer_setup()
target/iscsi: Convert timers to use timer_setup()
RAS/CEC: Convert timers to use timer_setup()
usb: usbtest: Convert timers to use timer_setup()
drm: gma500: Convert timers to use timer_setup()
drivers/gpu/drm/gma500/psb_lid.c | 8 +++---
drivers/ras/cec.c | 8 +++---
drivers/scsi/aic7xxx/aic79xx.h | 5 +---
drivers/scsi/aic7xxx/aic79xx_core.c | 29 ++++++---------------
drivers/scsi/aic7xxx/aic79xx_osm.h | 7 ------
drivers/scsi/csiostor/csio_hw.c | 15 +++++------
drivers/scsi/csiostor/csio_mb.c | 9 +++----
drivers/scsi/csiostor/csio_mb.h | 3 ++-
drivers/scsi/cxgbi/cxgb3i/cxgb3i.c | 8 +++---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 8 +++---
drivers/scsi/cxgbi/libcxgbi.c | 2 +-
drivers/scsi/hisi_sas/hisi_sas.h | 1 -
drivers/scsi/hisi_sas/hisi_sas_main.c | 14 +++++------
drivers/scsi/hisi_sas/hisi_sas_v1_hw.c | 6 ++---
drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 24 ++++++++----------
drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 2 +-
drivers/scsi/ibmvscsi/ibmvfc.c | 14 +++++------
drivers/scsi/ibmvscsi/ibmvscsi.c | 7 +++---
drivers/scsi/ipr.c | 30 +++++++++++-----------
drivers/scsi/libsas/sas_expander.c | 8 +++---
drivers/scsi/libsas/sas_init.c | 3 ++-
drivers/scsi/libsas/sas_scsi_host.c | 2 +-
drivers/scsi/lpfc/lpfc_crtn.h | 16 ++++++------
drivers/scsi/lpfc/lpfc_ct.c | 4 +--
drivers/scsi/lpfc/lpfc_els.c | 12 ++++-----
drivers/scsi/lpfc/lpfc_hbadisc.c | 7 +++---
drivers/scsi/lpfc/lpfc_init.c | 39 ++++++++++++-----------------
drivers/scsi/lpfc/lpfc_scsi.c | 4 +--
drivers/scsi/lpfc/lpfc_sli.c | 8 +++---
drivers/scsi/megaraid/megaraid_ioctl.h | 6 +++++
drivers/scsi/megaraid/megaraid_mbox.c | 26 +++++++++----------
drivers/scsi/megaraid/megaraid_mm.c | 27 ++++++++++----------
drivers/scsi/megaraid/megaraid_sas_base.c | 35 ++++++++++----------------
drivers/scsi/megaraid/megaraid_sas_fusion.c | 15 +++--------
drivers/scsi/mvsas/mv_init.c | 3 +--
drivers/scsi/mvsas/mv_sas.c | 15 ++++++-----
drivers/scsi/mvsas/mv_sas.h | 1 -
drivers/scsi/pm8001/pm8001_sas.c | 11 ++++----
drivers/scsi/pmcraid.c | 33 ++++++++++--------------
drivers/scsi/qla4xxx/ql4_os.c | 12 ++++-----
drivers/target/iscsi/iscsi_target.c | 2 ++
drivers/target/iscsi/iscsi_target_erl0.c | 12 +++------
drivers/target/iscsi/iscsi_target_erl0.h | 1 +
drivers/target/iscsi/iscsi_target_erl1.c | 10 +++-----
drivers/target/iscsi/iscsi_target_erl1.h | 1 +
drivers/target/iscsi/iscsi_target_login.c | 17 +++++++------
drivers/target/iscsi/iscsi_target_login.h | 1 +
drivers/target/iscsi/iscsi_target_nego.c | 25 ++++++++++--------
drivers/target/iscsi/iscsi_target_util.c | 29 +++++++--------------
drivers/target/iscsi/iscsi_target_util.h | 2 ++
drivers/usb/misc/usbtest.c | 22 ++++++++++------
include/scsi/libsas.h | 1 +
52 files changed, 271 insertions(+), 339 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 71%]
* [GIT PULL] timers-conversion updates for next (part 3)
@ 2017-11-02 23:05 72% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-11-02 23:05 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: linux-kernel
Hi Thomas,
Please pull these timer conversions for tip/timers/core. These are
various per-architecture changes, misc drivers not picked up by specific
maintainers, changes that depend on the timer_setup_on_stack() API, and
other things that got Acked/Reviewed along the way but were not picked
up by other maintainers (and which, at least currently, have no conflicts
in -next).
I'm currently carrying a "late rc1" tree as well, which is based on top
of -next, which has a handful more conversions that depend on various
trees, making them impossible to merge cleaning either via tip or via
a separate maintainer's tree. (This tree has the final treewide changes
too.)
Thanks!
-Kees
The following changes since commit 6082a6e44434a17f194048b7d48df56f148ec6d4:
kernel/time/Kconfig: Fix typo in comment (2017-11-02 12:50:34 +0100)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/timers-conversion-next3
for you to fetch changes up to 25b42fa8f8a45d863f704bbfe3c79a46958cf4dc:
drivers/sgi-xp: Convert timers to use timer_setup() (2017-11-02 15:50:51 -0700)
----------------------------------------------------------------
various per-architecture conversions
several driver conversions not picked up by a specific maintainer
other Acked/Reviewed conversions to go through tip
----------------------------------------------------------------
Kees Cook (21):
rcu: Convert timers to use timer_setup()
fs/ncpfs: Convert timers to use timer_setup()
ACPI / APEI: Convert timers to use timer_setup()
drm/etnaviv: Convert timers to use timer_setup()
media: pvrusb2: Convert timers to use timer_setup()
watchdog: cpwd: Convert timers to use timer_setup()
watchdog: lpc18xx_wdt: Convert timers to use timer_setup()
powerpc/watchdog: Convert timers to use timer_setup()
x86, calgary: Convert timers to use timer_setup()
xtensa: Convert timers to use timer_setup()
ia64: Convert timers to use timer_setup()
ARM: footbridge: Convert timers to use timer_setup()
arm: pxa: Convert timers to use timer_setup()
mips: ip22/32: Convert timers to use timer_setup()
sparc/led: Convert timers to use timer_setup()
auxdisplay: Convert timers to use timer_setup()
hwrng/xgene-rng: Convert timers to use timer_setup()
drivers/macintosh: Convert timers to use timer_setup()
drivers/memstick: Convert timers to use timer_setup()
drivers/pcmcia: Convert timers to use timer_setup()
drivers/sgi-xp: Convert timers to use timer_setup()
arch/arm/mach-footbridge/dc21285.c | 26 +++++---------
arch/arm/mach-pxa/lubbock.c | 15 ++++----
arch/arm/mach-pxa/sharpsl_pm.c | 8 ++---
arch/ia64/include/asm/sn/bte.h | 4 ++-
arch/ia64/kernel/mca.c | 8 ++---
arch/ia64/kernel/salinfo.c | 5 ++-
arch/ia64/sn/kernel/bte.c | 12 ++++---
arch/ia64/sn/kernel/bte_error.c | 17 ++++-----
arch/ia64/sn/kernel/huberror.c | 2 +-
arch/ia64/sn/kernel/mca.c | 5 ++-
arch/mips/sgi-ip22/ip22-reset.c | 26 +++++++-------
arch/mips/sgi-ip32/ip32-reset.c | 21 ++++++-----
arch/powerpc/kernel/watchdog.c | 5 ++-
arch/sparc/kernel/led.c | 16 +++++----
arch/x86/kernel/pci-calgary_64.c | 8 ++---
arch/xtensa/platforms/iss/console.c | 9 +++--
arch/xtensa/platforms/iss/network.c | 13 +++----
drivers/acpi/apei/ghes.c | 7 ++--
drivers/auxdisplay/img-ascii-lcd.c | 10 +++---
drivers/auxdisplay/panel.c | 4 +--
drivers/char/hw_random/xgene-rng.c | 8 ++---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 7 ++--
drivers/macintosh/smu.c | 10 +++---
drivers/media/usb/pvrusb2/pvrusb2-hdw.c | 64 ++++++++++++++++++---------------
drivers/memstick/host/jmb38x_ms.c | 10 +++---
drivers/memstick/host/r592.c | 7 ++--
drivers/memstick/host/tifm_ms.c | 6 ++--
drivers/misc/sgi-xp/xpc_main.c | 15 ++++----
drivers/misc/sgi-xp/xpc_sn2.c | 15 ++++----
drivers/pcmcia/bcm63xx_pcmcia.c | 6 ++--
drivers/pcmcia/bfin_cf_pcmcia.c | 6 ++--
drivers/pcmcia/i82365.c | 6 ++--
drivers/pcmcia/omap_cf.c | 8 ++---
drivers/pcmcia/pd6729.c | 7 ++--
drivers/pcmcia/soc_common.c | 7 ++--
drivers/pcmcia/tcic.c | 8 ++---
drivers/pcmcia/yenta_socket.c | 7 ++--
drivers/watchdog/cpwd.c | 8 ++---
drivers/watchdog/lpc18xx_wdt.c | 13 +++----
fs/ncpfs/inode.c | 4 +--
fs/ncpfs/ncp_fs_sb.h | 2 +-
fs/ncpfs/sock.c | 6 ++--
kernel/rcu/rcutorture.c | 4 +--
kernel/rcu/tree_plugin.h | 9 ++---
44 files changed, 215 insertions(+), 249 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 72%]
* [GIT PULL] timers-conversion updates for next (part 4)
@ 2017-11-06 22:01 84% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-11-06 22:01 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: linux-kernel
Hi Thomas,
Please pull these timer conversions for tip/timers/core. These are a couple
fixes and more conversions that have either been reviewed or have been
pending on the list long enough.
I expect at least one more pull that will have the last scsi fix and one
netfilter conversion. After that, there are 10 patches that will all be
late rc1 since they depend on multiple trees.
Details of the conversion progress is here:
https://marc.info/?l=linux-next&m=151000446600975&w=2
Thanks!
-Kees
The following changes since commit c7c2f3d9e86c2f09a514247d1623f00850125636:
Merge tag 'timers-conversion-next3' of https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux into timers/core (2017-11-03 00:06:08 +0100)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/timers-conversion-next4
for you to fetch changes up to 5ea22086ed42bef8dde93f45a42a3ace486eb788:
block/aoe: discover_timer: Convert timers to use timer_setup() (2017-11-06 12:50:09 -0800)
----------------------------------------------------------------
- a couple fixes for less common build configurations
- more stragglers that have either been reviewed or gone long enough on list
----------------------------------------------------------------
Kees Cook (7):
ARM: footbridge: Fix typo in timer conversion
drivers/pcmcia: omap1: Fix error in automated timer conversion
crypto: Convert timers to use timer_setup()
mailbox: Convert timers to use timer_setup()
drbd: Convert timers to use timer_setup()
ide: Convert timers to use timer_setup()
block/aoe: discover_timer: Convert timers to use timer_setup()
arch/arm/mach-footbridge/dc21285.c | 2 +-
drivers/block/aoe/aoemain.c | 44 +++++++-----------------------------
drivers/block/drbd/drbd_int.h | 4 ++--
drivers/block/drbd/drbd_main.c | 18 ++++++---------
drivers/block/drbd/drbd_receiver.c | 2 +-
drivers/block/drbd/drbd_req.c | 4 ++--
drivers/block/drbd/drbd_req.h | 2 +-
drivers/block/drbd/drbd_worker.c | 8 +++----
drivers/crypto/axis/artpec6_crypto.c | 6 ++---
drivers/crypto/mv_cesa.c | 4 ++--
drivers/crypto/picoxcell_crypto.c | 7 +++---
drivers/ide/ide-io.c | 4 ++--
drivers/ide/ide-probe.c | 2 +-
drivers/mailbox/mailbox-altera.c | 12 +++++-----
drivers/pcmcia/omap_cf.c | 4 +++-
include/linux/ide.h | 2 +-
16 files changed, 47 insertions(+), 78 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 84%]
* [GIT PULL] timers-conversion updates for next (part 5)
@ 2017-11-08 23:59 89% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-11-08 23:59 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: linux-kernel
Hi Thomas,
Please pull these timer conversions for tip/timers/core. These are the last
of the pre-rc1 changes. The rest of the changes are for late-rc1 (due to
various tree dependencies). Following that are the tree-wide changes, and
the API adjustments and removals.
Thanks!
-Kees
The following changes since commit 1c10bbee8cf7c8df4e5d9e8ccc9754b200f625ff:
Merge tag 'timers-conversion-next4' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux into timers/core (2017-11-07 11:59:40 +0100)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/timers-conversion-next5
for you to fetch changes up to 3653bc95bcc7daa938c0fdcd64ff199ed8f7f208:
timer: Prepare to change all DEFINE_TIMER() callbacks (2017-11-08 15:54:09 -0800)
----------------------------------------------------------------
- qla2xxx patches have passed testing
- ipvs patches have been Acked
- prepare for more tree-wide DEFINE_TIMER() changes
----------------------------------------------------------------
Kees Cook (3):
scsi: qla2xxx: Convert timers to use timer_setup()
netfilter: ipvs: Convert timers to use timer_setup()
timer: Prepare to change all DEFINE_TIMER() callbacks
drivers/scsi/qla2xxx/qla_gbl.h | 6 +++---
drivers/scsi/qla2xxx/qla_init.c | 4 ++--
drivers/scsi/qla2xxx/qla_inline.h | 4 +---
drivers/scsi/qla2xxx/qla_mid.c | 2 +-
drivers/scsi/qla2xxx/qla_os.c | 11 +++++------
include/linux/timer.h | 8 ++++----
net/netfilter/ipvs/ip_vs_conn.c | 10 +++++-----
net/netfilter/ipvs/ip_vs_ctl.c | 7 +++----
net/netfilter/ipvs/ip_vs_est.c | 6 +++---
net/netfilter/ipvs/ip_vs_lblc.c | 11 ++++++-----
net/netfilter/ipvs/ip_vs_lblcr.c | 11 ++++++-----
11 files changed, 39 insertions(+), 41 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 89%]
* [GIT PULL] usercopy whitelisting for v4.15-rc1
@ 2017-11-13 7:29 70% Kees Cook
2017-11-16 7:45 92% ` Kees Cook
0 siblings, 1 reply; 200+ results
From: Kees Cook @ 2017-11-13 7:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, David Windsor, Paolo Bonzini
Hi,
Please pull these hardened usercopy whitelisting changes for v4.15-rc1.
This significantly narrows the areas of memory that can be copied to/from
userspace in the face of usercopy bugs.
Thanks!
-Kees
The following changes since commit 9e66317d3c92ddaab330c125dfe9d06eee268aff:
Linux 4.14-rc3 (2017-10-01 14:54:54 -0700)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/usercopy-v4.15-rc1
for you to fetch changes up to 3889a28c449c01cebe166e413a58742002c2352b:
lkdtm: Update usercopy tests for whitelisting (2017-11-08 15:40:04 -0800)
----------------------------------------------------------------
Currently, hardened usercopy performs dynamic bounds checking on slab
cache objects. This is good, but still leaves a lot of kernel memory
available to be copied to/from userspace in the face of bugs. To further
restrict what memory is available for copying, this creates a way to
whitelist specific areas of a given slab cache object for copying to/from
userspace, allowing much finer granularity of access control. Slab caches
that are never exposed to userspace can declare no whitelist for their
objects, thereby keeping them unavailable to userspace via dynamic copy
operations. (Note, an implicit form of whitelisting is the use of constant
sizes in usercopy operations and get_user()/put_user(); these bypass
hardened usercopy checks since these sizes cannot change at runtime.)
----------------------------------------------------------------
David Windsor (23):
usercopy: Prepare for usercopy whitelisting
usercopy: Enforce slab cache usercopy region boundaries
usercopy: Mark kmalloc caches as usercopy caches
dcache: Define usercopy region in dentry_cache slab cache
vfs: Define usercopy region in names_cache slab caches
vfs: Copy struct mount.mnt_id to userspace using put_user()
ext4: Define usercopy region in ext4_inode_cache slab cache
ext2: Define usercopy region in ext2_inode_cache slab cache
jfs: Define usercopy region in jfs_ip slab cache
befs: Define usercopy region in befs_inode_cache slab cache
exofs: Define usercopy region in exofs_inode_cache slab cache
orangefs: Define usercopy region in orangefs_inode_cache slab cache
ufs: Define usercopy region in ufs_inode_cache slab cache
vxfs: Define usercopy region in vxfs_inode slab cache
cifs: Define usercopy region in cifs_request slab cache
scsi: Define usercopy region in scsi_sense_cache slab cache
net: Define usercopy region in struct proto slab cache
ip: Define usercopy region in IP proto slab cache
caif: Define usercopy region in caif proto slab cache
sctp: Define usercopy region in SCTP proto slab cache
sctp: Copy struct sctp_sock.autoclose to userspace using put_user()
fork: Define usercopy region in mm_struct slab caches
fork: Define usercopy region in thread_stack slab caches
Kees Cook (8):
net: Restrict unwhitelisted proto caches to size 0
fork: Provide usercopy whitelisting for task_struct
x86: Implement thread_struct whitelist for hardened usercopy
arm64: Implement thread_struct whitelist for hardened usercopy
arm: Implement thread_struct whitelist for hardened usercopy
usercopy: Allow for temporary fallback for non-whitelisted usercopy
usercopy: Restrict non-usercopy caches to size 0
lkdtm: Update usercopy tests for whitelisting
Paolo Bonzini (2):
kvm: whitelist struct kvm_vcpu_arch
kvm: x86: fix KVM_XEN_HVM_CONFIG ioctl
arch/Kconfig | 11 +++++
arch/arm/Kconfig | 1 +
arch/arm/include/asm/processor.h | 7 +++
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/processor.h | 8 ++++
arch/x86/Kconfig | 1 +
arch/x86/include/asm/processor.h | 8 ++++
arch/x86/kvm/x86.c | 7 +--
drivers/misc/lkdtm.h | 4 +-
drivers/misc/lkdtm_core.c | 4 +-
drivers/misc/lkdtm_usercopy.c | 88 +++++++++++++++++++++-----------------
drivers/scsi/scsi_lib.c | 9 ++--
fs/befs/linuxvfs.c | 14 +++---
fs/cifs/cifsfs.c | 10 +++--
fs/dcache.c | 9 ++--
fs/exofs/super.c | 7 ++-
fs/ext2/super.c | 12 +++---
fs/ext4/super.c | 12 +++---
fs/fhandle.c | 3 +-
fs/freevxfs/vxfs_super.c | 8 +++-
fs/jfs/super.c | 8 ++--
fs/orangefs/super.c | 15 ++++---
fs/ufs/super.c | 13 +++---
include/linux/sched/task.h | 14 ++++++
include/linux/slab.h | 27 +++++++++---
include/linux/slab_def.h | 3 ++
include/linux/slub_def.h | 3 ++
include/linux/stddef.h | 2 +
include/net/sctp/structs.h | 9 +++-
include/net/sock.h | 2 +
kernel/fork.c | 31 +++++++++++---
mm/slab.c | 35 ++++++++++++---
mm/slab.h | 8 +++-
mm/slab_common.c | 54 ++++++++++++++++++-----
mm/slub.c | 46 ++++++++++++++++----
mm/usercopy.c | 12 ++++++
net/caif/caif_socket.c | 2 +
net/core/sock.c | 4 +-
net/ipv4/raw.c | 2 +
net/ipv6/raw.c | 2 +
net/sctp/socket.c | 10 ++++-
security/Kconfig | 12 ++++++
virt/kvm/kvm_main.c | 7 ++-
43 files changed, 407 insertions(+), 138 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 70%]
* Re: [GIT PULL] usercopy whitelisting for v4.15-rc1
2017-11-13 7:29 70% [GIT PULL] usercopy whitelisting for v4.15-rc1 Kees Cook
@ 2017-11-16 7:45 92% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-11-16 7:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: LKML, David Windsor, Paolo Bonzini
On Sun, Nov 12, 2017 at 11:29 PM, Kees Cook <keescook@chromium.org> wrote:
> Please pull these hardened usercopy whitelisting changes for v4.15-rc1.
> This significantly narrows the areas of memory that can be copied to/from
> userspace in the face of usercopy bugs.
Just wanted to make sure this pull request was still on your radar.
Let me know if you want me to do a full resend.
Thanks!
-Kees
> The following changes since commit 9e66317d3c92ddaab330c125dfe9d06eee268aff:
>
> Linux 4.14-rc3 (2017-10-01 14:54:54 -0700)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/usercopy-v4.15-rc1
>
> for you to fetch changes up to 3889a28c449c01cebe166e413a58742002c2352b:
>
> lkdtm: Update usercopy tests for whitelisting (2017-11-08 15:40:04 -0800)
>
> ----------------------------------------------------------------
> Currently, hardened usercopy performs dynamic bounds checking on slab
> cache objects. This is good, but still leaves a lot of kernel memory
> available to be copied to/from userspace in the face of bugs. To further
> restrict what memory is available for copying, this creates a way to
> whitelist specific areas of a given slab cache object for copying to/from
> userspace, allowing much finer granularity of access control. Slab caches
> that are never exposed to userspace can declare no whitelist for their
> objects, thereby keeping them unavailable to userspace via dynamic copy
> operations. (Note, an implicit form of whitelisting is the use of constant
> sizes in usercopy operations and get_user()/put_user(); these bypass
> hardened usercopy checks since these sizes cannot change at runtime.)
>
> ----------------------------------------------------------------
> David Windsor (23):
> usercopy: Prepare for usercopy whitelisting
> usercopy: Enforce slab cache usercopy region boundaries
> usercopy: Mark kmalloc caches as usercopy caches
> dcache: Define usercopy region in dentry_cache slab cache
> vfs: Define usercopy region in names_cache slab caches
> vfs: Copy struct mount.mnt_id to userspace using put_user()
> ext4: Define usercopy region in ext4_inode_cache slab cache
> ext2: Define usercopy region in ext2_inode_cache slab cache
> jfs: Define usercopy region in jfs_ip slab cache
> befs: Define usercopy region in befs_inode_cache slab cache
> exofs: Define usercopy region in exofs_inode_cache slab cache
> orangefs: Define usercopy region in orangefs_inode_cache slab cache
> ufs: Define usercopy region in ufs_inode_cache slab cache
> vxfs: Define usercopy region in vxfs_inode slab cache
> cifs: Define usercopy region in cifs_request slab cache
> scsi: Define usercopy region in scsi_sense_cache slab cache
> net: Define usercopy region in struct proto slab cache
> ip: Define usercopy region in IP proto slab cache
> caif: Define usercopy region in caif proto slab cache
> sctp: Define usercopy region in SCTP proto slab cache
> sctp: Copy struct sctp_sock.autoclose to userspace using put_user()
> fork: Define usercopy region in mm_struct slab caches
> fork: Define usercopy region in thread_stack slab caches
>
> Kees Cook (8):
> net: Restrict unwhitelisted proto caches to size 0
> fork: Provide usercopy whitelisting for task_struct
> x86: Implement thread_struct whitelist for hardened usercopy
> arm64: Implement thread_struct whitelist for hardened usercopy
> arm: Implement thread_struct whitelist for hardened usercopy
> usercopy: Allow for temporary fallback for non-whitelisted usercopy
> usercopy: Restrict non-usercopy caches to size 0
> lkdtm: Update usercopy tests for whitelisting
>
> Paolo Bonzini (2):
> kvm: whitelist struct kvm_vcpu_arch
> kvm: x86: fix KVM_XEN_HVM_CONFIG ioctl
>
> arch/Kconfig | 11 +++++
> arch/arm/Kconfig | 1 +
> arch/arm/include/asm/processor.h | 7 +++
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/processor.h | 8 ++++
> arch/x86/Kconfig | 1 +
> arch/x86/include/asm/processor.h | 8 ++++
> arch/x86/kvm/x86.c | 7 +--
> drivers/misc/lkdtm.h | 4 +-
> drivers/misc/lkdtm_core.c | 4 +-
> drivers/misc/lkdtm_usercopy.c | 88 +++++++++++++++++++++-----------------
> drivers/scsi/scsi_lib.c | 9 ++--
> fs/befs/linuxvfs.c | 14 +++---
> fs/cifs/cifsfs.c | 10 +++--
> fs/dcache.c | 9 ++--
> fs/exofs/super.c | 7 ++-
> fs/ext2/super.c | 12 +++---
> fs/ext4/super.c | 12 +++---
> fs/fhandle.c | 3 +-
> fs/freevxfs/vxfs_super.c | 8 +++-
> fs/jfs/super.c | 8 ++--
> fs/orangefs/super.c | 15 ++++---
> fs/ufs/super.c | 13 +++---
> include/linux/sched/task.h | 14 ++++++
> include/linux/slab.h | 27 +++++++++---
> include/linux/slab_def.h | 3 ++
> include/linux/slub_def.h | 3 ++
> include/linux/stddef.h | 2 +
> include/net/sctp/structs.h | 9 +++-
> include/net/sock.h | 2 +
> kernel/fork.c | 31 +++++++++++---
> mm/slab.c | 35 ++++++++++++---
> mm/slab.h | 8 +++-
> mm/slab_common.c | 54 ++++++++++++++++++-----
> mm/slub.c | 46 ++++++++++++++++----
> mm/usercopy.c | 12 ++++++
> net/caif/caif_socket.c | 2 +
> net/core/sock.c | 4 +-
> net/ipv4/raw.c | 2 +
> net/ipv6/raw.c | 2 +
> net/sctp/socket.c | 10 ++++-
> security/Kconfig | 12 ++++++
> virt/kvm/kvm_main.c | 7 ++-
> 43 files changed, 407 insertions(+), 138 deletions(-)
>
> --
> Kees Cook
> Pixel Security
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] tree-dependent timer conversions for v4.15-rc1
@ 2017-11-16 19:32 82% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-11-16 19:32 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: linux-kernel
Hi Thomas,
I'm not sure if I should send this to you or Linus, but since everything
else has gone through you, I'll start by sending it your way. Please
pull these timer conversions, now that all the dependent trees have
landed in Linus's tree. This is, obviously, based on Linus's tree,
not tip/timers/core.
After these, I'm waiting on a couple more trees to land in the merge
window (that have the final non-trivial conversions) before we can perform
the global Coccinelle script runs.
Thanks!
-Kees
The following changes since commit 2bf16b7a73caf3435f782e4170cfe563675e10f9:
Merge tag 'char-misc-4.15-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc (2017-11-16 09:10:59 -0800)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/for-linus-timer-conversions-v4.15-rc1
for you to fetch changes up to aa6f02a3d91f782bc11ece8e7bf3b7948ecade15:
s390: cmm: Convert timers to use timer_setup() (2017-11-16 10:26:53 -0800)
----------------------------------------------------------------
This is the last batch of timer conversions that were dependent on other trees.
With those trees now merged, these can land too.
----------------------------------------------------------------
Kees Cook (9):
drivers/firmware: psci: Convert timers to use timer_setup()
usb: usbatm: Convert timers to use timer_setup()
drm/i915/selftests: Convert timers to use timer_setup()
net/atm/mpc: Avoid open-coded assignment of timer callback function
block/laptop_mode: Convert timers to use timer_setup()
drm/vc4: Convert timers to use timer_setup()
drivers/net: cris: Convert timers to use timer_setup()
lightnvm: Convert timers to use timer_setup()
s390: cmm: Convert timers to use timer_setup()
arch/s390/mm/cmm.c | 8 +++---
block/blk-core.c | 10 ++++----
drivers/firmware/psci_checker.c | 4 +--
drivers/gpu/drm/i915/selftests/lib_sw_fence.c | 6 ++---
drivers/gpu/drm/vc4/vc4_bo.c | 9 +++----
drivers/gpu/drm/vc4/vc4_gem.c | 10 +++-----
drivers/lightnvm/pblk-core.c | 4 +--
drivers/lightnvm/pblk-gc.c | 6 ++---
drivers/lightnvm/pblk-init.c | 2 +-
drivers/lightnvm/pblk-rl.c | 6 ++---
drivers/lightnvm/pblk.h | 2 +-
drivers/lightnvm/rrpc.c | 6 ++---
drivers/net/cris/eth_v10.c | 36 +++++++++++++--------------
drivers/usb/atm/cxacru.c | 23 +++++++++++------
drivers/usb/atm/speedtch.c | 16 ++++++------
drivers/usb/atm/usbatm.c | 10 ++++----
include/linux/writeback.h | 2 +-
mm/page-writeback.c | 7 +++---
net/atm/mpc.c | 3 +--
19 files changed, 85 insertions(+), 85 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 82%]
* [GIT PULL] usercopy whitelisting for v4.15-rc1
@ 2017-11-17 16:54 67% Kees Cook
0 siblings, 1 reply; 200+ results
From: Kees Cook @ 2017-11-17 16:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Windsor, Paolo Bonzini, linux-kernel
Hi Linus,
Please pull these hardened usercopy changes for v4.15-rc1. This
significantly narrows the areas of memory that can be copied to/from
userspace in the face of usercopy bugs by adding explicit whitelisting for
slab cache regions. This has lived in -next for quite some time without
major problems, but there were some late-discovered missing whitelists,
so a fallback mode was added just to make sure we don't break anything. I
expect to remove the fallback mode in a release or two.
(Sorry if this pull request is a duplicate: I just don't want to miss
the merge window, given its potential for being shorter than usual.)
Thanks!
-Kees
The following changes since commit 9e66317d3c92ddaab330c125dfe9d06eee268aff:
Linux 4.14-rc3 (2017-10-01 14:54:54 -0700)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/usercopy-v4.15-rc1
for you to fetch changes up to 3889a28c449c01cebe166e413a58742002c2352b:
lkdtm: Update usercopy tests for whitelisting (2017-11-08 15:40:04 -0800)
----------------------------------------------------------------
Currently, hardened usercopy performs dynamic bounds checking on slab
cache objects. This is good, but still leaves a lot of kernel memory
available to be copied to/from userspace in the face of bugs. To further
restrict what memory is available for copying, this creates a way to
whitelist specific areas of a given slab cache object for copying to/from
userspace, allowing much finer granularity of access control. Slab caches
that are never exposed to userspace can declare no whitelist for their
objects, thereby keeping them unavailable to userspace via dynamic copy
operations. (Note, an implicit form of whitelisting is the use of constant
sizes in usercopy operations and get_user()/put_user(); these bypass
hardened usercopy checks since these sizes cannot change at runtime.)
----------------------------------------------------------------
David Windsor (23):
usercopy: Prepare for usercopy whitelisting
usercopy: Enforce slab cache usercopy region boundaries
usercopy: Mark kmalloc caches as usercopy caches
dcache: Define usercopy region in dentry_cache slab cache
vfs: Define usercopy region in names_cache slab caches
vfs: Copy struct mount.mnt_id to userspace using put_user()
ext4: Define usercopy region in ext4_inode_cache slab cache
ext2: Define usercopy region in ext2_inode_cache slab cache
jfs: Define usercopy region in jfs_ip slab cache
befs: Define usercopy region in befs_inode_cache slab cache
exofs: Define usercopy region in exofs_inode_cache slab cache
orangefs: Define usercopy region in orangefs_inode_cache slab cache
ufs: Define usercopy region in ufs_inode_cache slab cache
vxfs: Define usercopy region in vxfs_inode slab cache
cifs: Define usercopy region in cifs_request slab cache
scsi: Define usercopy region in scsi_sense_cache slab cache
net: Define usercopy region in struct proto slab cache
ip: Define usercopy region in IP proto slab cache
caif: Define usercopy region in caif proto slab cache
sctp: Define usercopy region in SCTP proto slab cache
sctp: Copy struct sctp_sock.autoclose to userspace using put_user()
fork: Define usercopy region in mm_struct slab caches
fork: Define usercopy region in thread_stack slab caches
Kees Cook (8):
net: Restrict unwhitelisted proto caches to size 0
fork: Provide usercopy whitelisting for task_struct
x86: Implement thread_struct whitelist for hardened usercopy
arm64: Implement thread_struct whitelist for hardened usercopy
arm: Implement thread_struct whitelist for hardened usercopy
usercopy: Allow for temporary fallback for non-whitelisted usercopy
usercopy: Restrict non-usercopy caches to size 0
lkdtm: Update usercopy tests for whitelisting
Paolo Bonzini (2):
kvm: whitelist struct kvm_vcpu_arch
kvm: x86: fix KVM_XEN_HVM_CONFIG ioctl
arch/Kconfig | 11 +++++
arch/arm/Kconfig | 1 +
arch/arm/include/asm/processor.h | 7 +++
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/processor.h | 8 ++++
arch/x86/Kconfig | 1 +
arch/x86/include/asm/processor.h | 8 ++++
arch/x86/kvm/x86.c | 7 +--
drivers/misc/lkdtm.h | 4 +-
drivers/misc/lkdtm_core.c | 4 +-
drivers/misc/lkdtm_usercopy.c | 88 +++++++++++++++++++++-----------------
drivers/scsi/scsi_lib.c | 9 ++--
fs/befs/linuxvfs.c | 14 +++---
fs/cifs/cifsfs.c | 10 +++--
fs/dcache.c | 9 ++--
fs/exofs/super.c | 7 ++-
fs/ext2/super.c | 12 +++---
fs/ext4/super.c | 12 +++---
fs/fhandle.c | 3 +-
fs/freevxfs/vxfs_super.c | 8 +++-
fs/jfs/super.c | 8 ++--
fs/orangefs/super.c | 15 ++++---
fs/ufs/super.c | 13 +++---
include/linux/sched/task.h | 14 ++++++
include/linux/slab.h | 27 +++++++++---
include/linux/slab_def.h | 3 ++
include/linux/slub_def.h | 3 ++
include/linux/stddef.h | 2 +
include/net/sctp/structs.h | 9 +++-
include/net/sock.h | 2 +
kernel/fork.c | 31 +++++++++++---
mm/slab.c | 35 ++++++++++++---
mm/slab.h | 8 +++-
mm/slab_common.c | 54 ++++++++++++++++++-----
mm/slub.c | 46 ++++++++++++++++----
mm/usercopy.c | 12 ++++++
net/caif/caif_socket.c | 2 +
net/core/sock.c | 4 +-
net/ipv4/raw.c | 2 +
net/ipv6/raw.c | 2 +
net/sctp/socket.c | 10 ++++-
security/Kconfig | 12 ++++++
virt/kvm/kvm_main.c | 7 ++-
43 files changed, 407 insertions(+), 138 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 67%]
* Re: [GIT PULL] usercopy whitelisting for v4.15-rc1
@ 2017-11-17 20:35 91% ` Kees Cook
0 siblings, 1 reply; 200+ results
From: Kees Cook @ 2017-11-17 20:35 UTC (permalink / raw)
To: Linus Torvalds, Paolo Bonzini; +Cc: David Windsor, Linux Kernel Mailing List
On Fri, Nov 17, 2017 at 9:45 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 17/11/2017 18:35, Linus Torvalds wrote:
>> Honestly, I'm unlikely to pull this at all this merge window, simply
>> because I won't have time for it. This merge window is not going to be
>> one where I can take a leisurely look at something like this.
>>
>> If you can make a smaller pull request that introduces the
>> infrastructure, but that _obviously_ cannot actually break anything,
>> that would be more likely to be palatable.
>
> As someone that was actually bitten by this stuff, and had a closer look
> at the usercopy whitelisting stuff... This one is really fail-fast
> (oopses all around if you forget to patch something), and with hardly
This is why I introduced the fallback mode: with both kvm and sctp
(ipv6) not noticed until late in the development cycle, I became much
less satisfied it had gotten sufficient testing. I wanted to make sure
there was a way for the series to land without actually breaking
things due to any missed whitelists.
> any configuration dependency. It's certainly a lot less scary to me
> than the GCC plugin stuff.
Agreed: this is a different type of change entirely. The GCC plugins
tend to be pretty invasive and non-discoverable. I prefer stuff like
this series, which is all visible in the code.
> But I don't want to ruin your Thanksgiving, so if Kees and/or you choose
> not to do this pull request---please do pull a subset, even after -rc1.
> It's easy enough to drop the final patch that changes whitelisting to
> blacklisting, and it'd be one less series bouncing around and touching
> files in several subsystems.
With the fallback mode, missed whitelists generate a WARN and are
allowed, so this series effectively only introduces tight controls on
the places where a whitelist is specifically introduced. And I went to
great lengths to document each whitelist usage in the commit logs.
I would agree it would be nice to get at least a subset of this in,
though. Linus, what would make you most comfortable?
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 91%]
* Re: [GIT PULL] usercopy whitelisting for v4.15-rc1
@ 2017-11-17 22:19 92% ` Kees Cook
1 sibling, 0 replies; 200+ results
From: Kees Cook @ 2017-11-17 22:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Paolo Bonzini, David Windsor, Linux Kernel Mailing List
On Fri, Nov 17, 2017 at 1:13 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> As long as you see your hardening efforts primarily as a "let me kill
> the machine/process on bad behavior", I will stop taking those shit
> patches.
Yes, this is entirely clear. This is why I adjusted this series (in
multiple places) to use WARN, etc etc. And why I went to great lengths
to document the rationale, effects, and alloc/use paths so when
something went wrong it would be easy to see what was happening and
why.
> So the hardening efforts should instead _start_ from the standpoint of
> "let's warn about what looks dangerous, and maybe in a _year_ when
> we've warned for a long time, and we are confident that we've actually
> caught all the normal cases, _then_ we can start taking more drastic
> measures".
Understood: I think my main flaw in helping bring these defenses to
the kernel has been thinking they can be fully tested during a single
development cycle, and this mistake was made quite clear this cycle,
which is why I adjusted the series like I did.
> Right now, the biggest problem for me is that the whole thing makes me
> uncomfortable, because I think the people involved are coming from a
> completely unacceptable model to begin with.
>
> And we had this exact issue with the _previous_ user mode access
> hardening. People apparently didn't learn a goddamn thing.
Well, I'd like to think I did learn something, since I fixed up this
series _before_ you yelled at me. :)
I'll make further adjustments and try again for v4.16.
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] usercopy whitelisting for v4.15-rc1
@ 2017-11-21 0:42 73% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-11-21 0:42 UTC (permalink / raw)
To: Matthew Garrett
Cc: Linus Torvalds, Paolo Bonzini, David Windsor, Linux Kernel Mailing List
On Mon, Nov 20, 2017 at 3:29 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> From a practical perspective this does feel like a completely reasonable
> request - when changing the semantics of kernel APIs in ways that aren't
> amenable to automated analysis, doing so in a way that generates
> warnings rather than triggering breakage is pretty clearly a preferable
> approach. But these features often start off seeming simple and then
> devolving into rounds of "ok just one more fix and we'll have
> everything" and by then it's easy to have lost track of the amount of
> complexity that's developed as a result. Formalising the Right Way of
> approaching these problems would possibly help avoid this kind of
> problem in future - I'll try to write something up for
> Documentation/process.
I'm always trying to balance the requests from both ends of the
security defense spectrum. One of the most common requests I get from
people who are strongly interested in the defenses is "can this please
be enabled by default?" And then I have to explain that it sometimes
takes time for code to shake out, and it sometimes takes time for
developers to trust it, etc. This is rarely a comfort to them, but
they tend to be glad they can turn some config knob to enable the
"strongest" version, etc, because for them, a false positive is no big
deal. At the other end is the requirement that new stuff should not
break the system. Both are reasonable perspectives, but if we violate
the latter, the defense will never end up in the kernel in the first
place.
The implicit process tends to be: land a defense that is optional,
distros enable it by default, kernel enables it by default. My sense
is that the span for these steps is about 3 years. There are countless
examples, but one of the more recent is x86 KASLR. Optional (Jun 2014,
v3.14), then distro default (e.g. Ubuntu 16.10, Oct 2016), then kernel
default (Jul 2017, v4.12). (And, in my opinion, this takes way too
long. But I'd rather have the defense at all.)
The trouble tends to be even in the "optional" phase, where it may be
optional but still very disruptive. If you were using KASLR but there
was a bug, it was basically going to be fatal to the system. So, my
historical perspective for other less disruptive defenses was "oh
good, it's only BUG(), that's WAY better than taking out the entire
system", but as Linus has pointed out in several threads, BUG() can
frequently lead to that too, which is not acceptable.
A variation on "new stuff should not break the system" comes from
things that LOOK like they can't break the system (i.e. disallowing
some pathological condition that would seem to be entirely reasonable
to disallow), and then discovering that stuff does, actually, use a
pathological condition in the real world (e.g. refcount underflows,
memcpy beyond the end of a short source string, 3rd party drivers
reading directly from userspace memory). And then there's just plain
bugs in defenses (e.g. missed usercopy whitelist for SCTPv6). Handling
these conditions means that in addition to being optional, a new
defense frequently has to also be WARN()-only initially.
Though, even then, there is a spectrum of defense capabilities. KASLR
couldn't WARN() initially since it's an architectural state. The
refcount_t API doesn't really need to be stronger than WARN() because
it can defend against overflow while leaving everything running fine.
And here, as already done, usercopy whitelisting needs to WARN() for
its initial implementation to shake out any hard-to-find cases before
becoming more aggressive.
With all this in mind, it can be tricky to find a way to provide the
right level of initial defense behavior that also has a knob for the
users that want to accept the risk of false positives. I'll keep
trying to get it right and keeping helping others find the right path.
We'll get there, steady progress, etc, etc. :)
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 73%]
* [GIT PULL] final timer conversion update for v4.15-rc1
@ 2017-11-22 0:19 39% Kees Cook
2017-11-22 0:41 92% ` Kees Cook
0 siblings, 1 reply; 200+ results
From: Kees Cook @ 2017-11-22 0:19 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: linux-kernel
Hi Thomas,
Please pull and forward this final set of changes needed to finish the
timer conversions, intended for v4.15-rc1. All the dependent trees have
landed, so this is it. The bulk of the changes are the treewide bits in
the middle. Their commit logs are rather long since Linus had
recommended to me that I include the script in the log, and didn't seem
to mind when I mentioned they might be very long. :)
Thanks!
-Kees
The following changes since commit 0c86a6bd85ff0629cd2c5141027fc1c8bb6cde9c:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2017-11-21 05:56:12 -1000)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/for-linus-timers-conversion-final-v4.15-rc1
for you to fetch changes up to c10d4a0af0eb5d549193de2593791d1dd29895db:
treewide: Remove TIMER_FUNC_TYPE cast (2017-11-21 15:57:16 -0800)
----------------------------------------------------------------
- final batch of "non trivial" timer conversions (multi-tree dependencies,
things Coccinelle couldn't handle, etc).
- treewide conversions via Coccinelle, in 4 steps:
- DEFINE_TIMER() functions converted to struct timer_list * argument
- init_timer() -> setup_timer()
- setup_timer() -> timer_setup()
- setup_timer() -> timer_setup() (with a single embedded structure)
- deprecated timer API removals (init_timer(), setup_*timer())
- finalization of new API (remove global casts)
----------------------------------------------------------------
Kees Cook (22):
drivers/firmware: psci: Convert timers to use timer_setup()
usb: usbatm: Convert timers to use timer_setup()
drm/i915/selftests: Convert timers to use timer_setup()
net/atm/mpc: Avoid open-coded assignment of timer callback function
block/laptop_mode: Convert timers to use timer_setup()
drm/vc4: Convert timers to use timer_setup()
drivers/net: cris: Convert timers to use timer_setup()
lightnvm: Convert timers to use timer_setup()
s390: cmm: Convert timers to use timer_setup()
treewide: Switch DEFINE_TIMER callbacks to struct timer_list *
treewide: init_timer() -> setup_timer()
treewide: setup_timer() -> timer_setup()
treewide: setup_timer() -> timer_setup() (2 field)
timer: Remove init_timer() interface
timer: Remove setup_*timer() interface
Coccinelle: Remove setup_timer.cocci
timer: Pass timer_list pointer to callbacks unconditionally
timer: Switch callback prototype to take struct timer_list * argument
timer: Remove unused data arguments from macros
timer: Pass function down to initialization routines
timer: Remove redundant __setup_timer*() macros
treewide: Remove TIMER_FUNC_TYPE cast
Documentation/core-api/local_ops.rst | 10 +-
arch/alpha/kernel/srmcons.c | 7 +-
arch/arm/mach-iop32x/n2100.c | 5 +-
arch/arm/mach-ixp4xx/dsmg600-setup.c | 4 +-
arch/arm/mach-ixp4xx/nas100d-setup.c | 4 +-
arch/arm/mach-orion5x/db88f5281-setup.c | 4 +-
arch/blackfin/kernel/nmi.c | 5 +-
arch/m68k/amiga/amisound.c | 4 +-
arch/m68k/mac/macboing.c | 4 +-
arch/mips/lasat/picvue_proc.c | 4 +-
arch/mips/mti-malta/malta-display.c | 4 +-
arch/parisc/kernel/pdc_cons.c | 4 +-
arch/powerpc/kernel/tau_6xx.c | 4 +-
arch/powerpc/kvm/booke.c | 7 +-
arch/powerpc/oprofile/op_model_cell.c | 8 +-
arch/powerpc/platforms/cell/spufs/sched.c | 8 +-
arch/powerpc/platforms/powermac/low_i2c.c | 6 +-
arch/s390/kernel/time.c | 4 +-
arch/s390/mm/cmm.c | 8 +-
arch/sh/drivers/heartbeat.c | 6 +-
arch/sh/drivers/pci/common.c | 16 +-
arch/sh/drivers/push-switch.c | 9 +-
block/blk-core.c | 10 +-
block/blk-stat.c | 6 +-
block/blk-throttle.c | 9 +-
drivers/atm/ambassador.c | 9 +-
drivers/atm/firestream.c | 8 +-
drivers/atm/horizon.c | 8 +-
drivers/atm/idt77105.c | 8 +-
drivers/atm/idt77252.c | 6 +-
drivers/atm/iphase.c | 4 +-
drivers/atm/lanai.c | 8 +-
drivers/atm/nicstar.c | 8 +-
drivers/base/power/wakeup.c | 2 +-
drivers/block/DAC960.c | 9 +-
drivers/block/DAC960.h | 2 +-
drivers/block/aoe/aoecmd.c | 2 +-
drivers/block/ataflop.c | 16 +-
drivers/block/rsxx/cregs.c | 7 +-
drivers/block/rsxx/dma.c | 7 +-
drivers/block/skd_main.c | 6 +-
drivers/block/sunvdc.c | 9 +-
drivers/block/swim3.c | 2 +-
drivers/block/umem.c | 5 +-
drivers/block/xsysace.c | 6 +-
drivers/char/dtlk.c | 4 +-
drivers/char/hangcheck-timer.c | 4 +-
drivers/char/ipmi/bt-bmc.c | 7 +-
drivers/char/ipmi/ipmi_msghandler.c | 4 +-
drivers/char/ipmi/ipmi_si_intf.c | 6 +-
drivers/char/ipmi/ipmi_ssif.c | 7 +-
drivers/char/nwbutton.c | 4 +-
drivers/char/nwbutton.h | 2 +-
drivers/char/rtc.c | 4 +-
drivers/char/tpm/tpm-dev-common.c | 7 +-
drivers/firmware/psci_checker.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 8 +-
drivers/gpu/drm/drm_vblank.c | 11 +-
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 6 +-
drivers/gpu/drm/i2c/tda998x_drv.c | 7 +-
drivers/gpu/drm/i915/selftests/lib_sw_fence.c | 6 +-
drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 7 +-
drivers/gpu/drm/msm/msm_gpu.c | 7 +-
drivers/gpu/drm/omapdrm/dss/dsi.c | 6 +-
drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 6 +-
drivers/gpu/drm/vc4/vc4_bo.c | 9 +-
drivers/gpu/drm/vc4/vc4_gem.c | 10 +-
drivers/gpu/drm/vgem/vgem_fence.c | 6 +-
drivers/gpu/drm/via/via_dmablit.c | 7 +-
drivers/hid/hid-appleir.c | 7 +-
drivers/hid/hid-prodikeys.c | 7 +-
drivers/hid/hid-wiimote-core.c | 6 +-
drivers/iio/common/ssp_sensors/ssp_dev.c | 6 +-
drivers/infiniband/hw/mlx5/mr.c | 6 +-
drivers/infiniband/hw/mthca/mthca_catas.c | 8 +-
drivers/infiniband/hw/nes/nes_verbs.c | 2 +-
drivers/input/gameport/gameport.c | 7 +-
drivers/input/input.c | 2 +-
drivers/input/joystick/db9.c | 6 +-
drivers/input/joystick/gamecon.c | 6 +-
drivers/input/joystick/turbografx.c | 6 +-
drivers/input/touchscreen/s3c2410_ts.c | 2 +-
drivers/iommu/iova.c | 8 +-
drivers/isdn/capi/capidrv.c | 6 +-
drivers/isdn/divert/isdn_divert.c | 9 +-
drivers/isdn/hardware/eicon/divasi.c | 9 +-
drivers/isdn/hardware/mISDN/hfcmulti.c | 8 +-
drivers/isdn/hardware/mISDN/hfcpci.c | 10 +-
drivers/isdn/hardware/mISDN/mISDNisar.c | 10 +-
drivers/isdn/i4l/isdn_common.c | 5 +-
drivers/isdn/i4l/isdn_net.c | 9 +-
drivers/isdn/i4l/isdn_ppp.c | 9 +-
drivers/isdn/i4l/isdn_tty.c | 7 +-
drivers/lightnvm/pblk-core.c | 4 +-
drivers/lightnvm/pblk-gc.c | 6 +-
drivers/lightnvm/pblk-init.c | 2 +-
drivers/lightnvm/pblk-rl.c | 6 +-
drivers/lightnvm/pblk.h | 2 +-
drivers/lightnvm/rrpc.c | 6 +-
drivers/media/common/saa7146/saa7146_vbi.c | 2 +-
drivers/media/platform/fsl-viu.c | 7 +-
drivers/media/platform/s5p-mfc/s5p_mfc.c | 8 +-
.../media/platform/sti/c8sectpfe/c8sectpfe-core.c | 7 +-
drivers/media/platform/vim2m.c | 6 +-
drivers/media/usb/au0828/au0828-dvb.c | 8 +-
drivers/media/usb/au0828/au0828-video.c | 14 +-
drivers/memstick/core/ms_block.c | 7 +-
drivers/mfd/rtsx_usb.c | 6 +-
drivers/mmc/core/host.c | 6 +-
drivers/mtd/sm_ftl.c | 6 +-
drivers/net/caif/caif_hsi.c | 21 +-
drivers/net/cris/eth_v10.c | 36 ++-
drivers/net/dsa/mv88e6xxx/phy.c | 7 +-
drivers/net/eql.c | 6 +-
drivers/net/ethernet/adi/bfin_mac.c | 9 +-
drivers/net/ethernet/agere/et131x.c | 7 +-
drivers/net/ethernet/amazon/ena/ena_netdev.c | 7 +-
drivers/net/ethernet/aquantia/atlantic/aq_nic.c | 14 +-
drivers/net/ethernet/atheros/atl1c/atl1c_main.c | 8 +-
drivers/net/ethernet/atheros/atl1e/atl1e_main.c | 8 +-
drivers/net/ethernet/atheros/atlx/atl1.c | 8 +-
drivers/net/ethernet/atheros/atlx/atl2.c | 15 +-
drivers/net/ethernet/broadcom/b44.c | 6 +-
drivers/net/ethernet/broadcom/bnx2.c | 6 +-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 6 +-
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 6 +-
drivers/net/ethernet/broadcom/tg3.c | 6 +-
drivers/net/ethernet/cisco/enic/enic_clsf.c | 4 +-
drivers/net/ethernet/cisco/enic/enic_clsf.h | 5 +-
drivers/net/ethernet/cisco/enic/enic_main.c | 7 +-
drivers/net/ethernet/marvell/mv643xx_eth.c | 13 +-
drivers/net/ethernet/marvell/pxa168_eth.c | 7 +-
drivers/net/ethernet/marvell/skge.c | 6 +-
drivers/net/ethernet/marvell/sky2.c | 6 +-
drivers/net/ethernet/myricom/myri10ge/myri10ge.c | 7 +-
.../net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 8 +-
drivers/net/ethernet/pasemi/pasemi_mac.c | 7 +-
drivers/net/ethernet/qlogic/qla3xxx.c | 6 +-
drivers/net/ethernet/rocker/rocker_ofdpa.c | 7 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 15 +-
drivers/net/ethernet/synopsys/dwc-xlgmac-net.c | 7 +-
drivers/net/ethernet/ti/cpsw_ale.c | 6 +-
drivers/net/ethernet/ti/netcp_ethss.c | 7 +-
drivers/net/ethernet/ti/tlan.c | 6 +-
drivers/net/ethernet/toshiba/spider_net.c | 16 +-
drivers/net/hamradio/scc.c | 8 +-
drivers/net/slip/slip.c | 16 +-
drivers/net/tun.c | 8 +-
drivers/net/wan/hdlc_ppp.c | 6 +-
drivers/net/wireless/atmel/at76c50x-usb.c | 4 +-
.../wireless/broadcom/brcm80211/brcmfmac/btcoex.c | 6 +-
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 7 +-
.../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 7 +-
drivers/net/wireless/intel/iwlwifi/dvm/main.c | 14 +-
drivers/net/wireless/intel/iwlwifi/dvm/tt.c | 18 +-
drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 7 +-
drivers/net/wireless/intersil/hostap/hostap_ap.c | 8 +-
drivers/net/wireless/intersil/hostap/hostap_hw.c | 17 +-
.../net/wireless/intersil/orinoco/orinoco_usb.c | 6 +-
drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 2 +-
drivers/net/wireless/quantenna/qtnfmac/core.c | 2 +-
drivers/net/wireless/ray_cs.c | 12 +-
drivers/net/wireless/ti/wlcore/main.c | 7 +-
drivers/net/xen-netfront.c | 7 +-
drivers/nfc/nfcmrvl/fw_dnld.c | 7 +-
drivers/nfc/pn533/pn533.c | 8 +-
drivers/nfc/st-nci/ndlc.c | 17 +-
drivers/nfc/st-nci/se.c | 19 +-
drivers/nfc/st21nfca/se.c | 19 +-
drivers/ntb/test/ntb_pingpong.c | 8 +-
drivers/platform/x86/sony-laptop.c | 4 +-
drivers/pps/clients/pps-ktimer.c | 4 +-
drivers/rtc/rtc-dev.c | 6 +-
drivers/s390/block/dasd.c | 20 +-
drivers/s390/char/sclp.c | 2 +-
drivers/s390/net/fsm.c | 11 +-
drivers/s390/scsi/zfcp_fsf.c | 4 +-
drivers/scsi/aic94xx/aic94xx_hwi.c | 2 +-
drivers/scsi/aic94xx/aic94xx_tmf.c | 2 +-
drivers/scsi/arcmsr/arcmsr_hba.c | 14 +-
drivers/scsi/arm/fas216.c | 8 +-
drivers/scsi/be2iscsi/be_main.c | 4 +-
drivers/scsi/bfa/bfad.c | 8 +-
drivers/scsi/bfa/bfad_drv.h | 2 +-
drivers/scsi/bnx2fc/bnx2fc_tgt.c | 16 +-
drivers/scsi/cxgbi/cxgb3i/cxgb3i.c | 4 +-
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 4 +-
drivers/scsi/esas2r/esas2r_main.c | 10 +-
drivers/scsi/fcoe/fcoe_ctlr.c | 8 +-
drivers/scsi/fnic/fnic_main.c | 14 +-
drivers/scsi/hisi_sas/hisi_sas_main.c | 4 +-
drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 6 +-
drivers/scsi/ipr.c | 8 +-
drivers/scsi/libfc/fc_fcp.c | 6 +-
drivers/scsi/libsas/sas_expander.c | 2 +-
drivers/scsi/libsas/sas_scsi_host.c | 2 +-
drivers/scsi/mvsas/mv_sas.c | 4 +-
drivers/scsi/ncr53c8xx.c | 8 +-
drivers/scsi/pm8001/pm8001_sas.c | 4 +-
drivers/scsi/pmcraid.c | 10 +-
drivers/scsi/sym53c8xx_2/sym_glue.c | 8 +-
drivers/staging/greybus/operation.c | 7 +-
drivers/staging/irda/include/net/irda/timer.h | 2 +-
drivers/staging/lustre/lnet/lnet/net_fault.c | 6 +-
drivers/staging/lustre/lustre/ptlrpc/service.c | 9 +-
drivers/staging/media/imx/imx-ic-prpencvf.c | 7 +-
drivers/staging/media/imx/imx-media-csi.c | 7 +-
drivers/staging/most/hdm-usb/hdm_usb.c | 7 +-
.../staging/rtl8192u/ieee80211/ieee80211_softmac.c | 16 +-
drivers/staging/rtl8712/recv_linux.c | 9 +-
drivers/staging/rtl8712/rtl8712_led.c | 9 +-
drivers/staging/speakup/main.c | 4 +-
drivers/staging/speakup/synth.c | 2 +-
drivers/staging/unisys/visorbus/visorbus_main.c | 6 +-
drivers/staging/unisys/visornic/visornic_main.c | 8 +-
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 8 +-
drivers/target/target_core_user.c | 7 +-
drivers/tty/cyclades.c | 4 +-
drivers/tty/ipwireless/hardware.c | 11 +-
drivers/tty/isicom.c | 4 +-
drivers/tty/moxa.c | 4 +-
drivers/tty/n_gsm.c | 12 +-
drivers/tty/n_r3964.c | 8 +-
drivers/tty/rocket.c | 4 +-
drivers/tty/serial/8250/8250_core.c | 4 +-
drivers/tty/serial/crisv10.c | 4 +-
drivers/tty/serial/fsl_lpuart.c | 7 +-
drivers/tty/serial/ifx6x60.c | 7 +-
drivers/tty/serial/imx.c | 6 +-
drivers/tty/serial/kgdb_nmi.c | 6 +-
drivers/tty/serial/max3100.c | 7 +-
drivers/tty/serial/mux.c | 4 +-
drivers/tty/serial/pnx8xxx_uart.c | 7 +-
drivers/tty/serial/sa1100.c | 7 +-
drivers/tty/serial/sh-sci.c | 16 +-
drivers/tty/serial/sn_console.c | 6 +-
drivers/tty/synclink.c | 8 +-
drivers/tty/synclink_gt.c | 16 +-
drivers/tty/synclinkmp.c | 17 +-
drivers/tty/vt/keyboard.c | 2 +-
drivers/tty/vt/vt.c | 4 +-
drivers/usb/atm/cxacru.c | 23 +-
drivers/usb/atm/speedtch.c | 16 +-
drivers/usb/atm/usbatm.c | 10 +-
drivers/usb/core/hcd.c | 8 +-
drivers/usb/dwc2/hcd.c | 7 +-
drivers/usb/dwc2/hcd_queue.c | 7 +-
drivers/usb/gadget/udc/at91_udc.c | 7 +-
drivers/usb/gadget/udc/dummy_hcd.c | 8 +-
drivers/usb/gadget/udc/m66592-udc.c | 6 +-
drivers/usb/gadget/udc/omap_udc.c | 8 +-
drivers/usb/gadget/udc/pxa25x_udc.c | 6 +-
drivers/usb/gadget/udc/r8a66597-udc.c | 6 +-
drivers/usb/host/ohci-hcd.c | 9 +-
drivers/usb/host/oxu210hp-hcd.c | 6 +-
drivers/usb/host/r8a66597-hcd.c | 7 +-
drivers/usb/host/sl811-hcd.c | 6 +-
drivers/usb/host/uhci-hcd.c | 3 +-
drivers/usb/host/uhci-q.c | 4 +-
drivers/usb/host/xhci.c | 8 +-
drivers/usb/serial/mos7840.c | 15 +-
drivers/usb/storage/realtek_cr.c | 7 +-
drivers/uwb/drp.c | 6 +-
drivers/uwb/neh.c | 8 +-
drivers/uwb/rsv.c | 15 +-
drivers/uwb/uwb-internal.h | 2 +-
drivers/watchdog/alim7101_wdt.c | 4 +-
drivers/watchdog/at91sam9_wdt.c | 6 +-
drivers/watchdog/bcm47xx_wdt.c | 9 +-
drivers/watchdog/bcm63xx_wdt.c | 4 +-
drivers/watchdog/cpu5wdt.c | 4 +-
drivers/watchdog/machzwd.c | 4 +-
drivers/watchdog/mixcomwd.c | 4 +-
drivers/watchdog/mpc8xxx_wdt.c | 7 +-
drivers/watchdog/mtx-1_wdt.c | 4 +-
drivers/watchdog/nuc900_wdt.c | 4 +-
drivers/watchdog/pcwd.c | 4 +-
drivers/watchdog/pika_wdt.c | 4 +-
drivers/watchdog/rdc321x_wdt.c | 4 +-
drivers/watchdog/sbc60xxwdt.c | 4 +-
drivers/watchdog/sc520_wdt.c | 4 +-
drivers/watchdog/shwdt.c | 6 +-
drivers/watchdog/via_wdt.c | 4 +-
drivers/watchdog/w83877f_wdt.c | 4 +-
drivers/xen/grant-table.c | 4 +-
fs/ocfs2/cluster/tcp.c | 9 +-
fs/pstore/platform.c | 4 +-
include/linux/kthread.h | 10 +-
include/linux/timer.h | 120 +++------
include/linux/workqueue.h | 17 +-
include/linux/writeback.h | 2 +-
kernel/irq/spurious.c | 4 +-
kernel/kthread.c | 2 +-
kernel/padata.c | 6 +-
kernel/time/clocksource.c | 5 +-
kernel/time/timer.c | 40 +--
kernel/workqueue.c | 2 +-
lib/random32.c | 4 +-
mm/page-writeback.c | 7 +-
net/802/garp.c | 6 +-
net/802/mrp.c | 13 +-
net/appletalk/aarp.c | 4 +-
net/appletalk/ddp.c | 7 +-
net/atm/lec.c | 6 +-
net/atm/mpc.c | 3 +-
net/batman-adv/tp_meter.c | 14 +-
net/bluetooth/hidp/core.c | 7 +-
net/bluetooth/rfcomm/core.c | 12 +-
net/bluetooth/sco.c | 6 +-
net/can/proc.c | 4 +-
net/core/drop_monitor.c | 7 +-
net/core/gen_estimator.c | 6 +-
net/core/neighbour.c | 14 +-
net/decnet/dn_route.c | 8 +-
net/decnet/dn_timer.c | 8 +-
net/ipv4/igmp.c | 20 +-
net/ipv4/ipmr.c | 9 +-
net/ipv6/addrconf.c | 9 +-
net/ipv6/ip6_fib.c | 10 +-
net/ipv6/ip6_flowlabel.c | 4 +-
net/ipv6/ip6mr.c | 9 +-
net/ipv6/mcast.c | 33 ++-
net/lapb/lapb_timer.c | 4 +-
net/ncsi/ncsi-manage.c | 15 +-
net/netfilter/nf_conntrack_expect.c | 7 +-
net/netfilter/nfnetlink_log.c | 8 +-
net/netfilter/xt_IDLETIMER.c | 7 +-
net/netfilter/xt_LED.c | 8 +-
net/netrom/af_netrom.c | 2 +-
net/netrom/nr_loopback.c | 4 +-
net/netrom/nr_timer.c | 2 +-
net/nfc/nci/core.c | 14 +-
net/rose/rose_link.c | 4 +-
net/rose/rose_timer.c | 12 +-
net/rxrpc/call_object.c | 7 +-
net/sunrpc/svc_xprt.c | 2 +-
net/wireless/lib80211.c | 11 +-
net/x25/af_x25.c | 2 +-
net/x25/x25_link.c | 8 +-
net/x25/x25_timer.c | 2 +-
net/xfrm/xfrm_state.c | 9 +-
scripts/coccinelle/api/setup_timer.cocci | 277 ---------------------
security/keys/gc.c | 4 +-
sound/usb/line6/driver.c | 2 +-
344 files changed, 1212 insertions(+), 1705 deletions(-)
delete mode 100644 scripts/coccinelle/api/setup_timer.cocci
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 39%]
* Re: [GIT PULL] final timer conversion update for v4.15-rc1
2017-11-22 0:19 39% [GIT PULL] final timer conversion update " Kees Cook
@ 2017-11-22 0:41 92% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-11-22 0:41 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: LKML
On Tue, Nov 21, 2017 at 4:19 PM, Kees Cook <keescook@chromium.org> wrote:
> Hi Thomas,
>
> Please pull and forward this final set of changes needed to finish the
> timer conversions, intended for v4.15-rc1. All the dependent trees have
> landed, so this is it. The bulk of the changes are the treewide bits in
> the middle. Their commit logs are rather long since Linus had
> recommended to me that I include the script in the log, and didn't seem
> to mind when I mentioned they might be very long. :)
>
> Thanks!
>
> -Kees
>
> The following changes since commit 0c86a6bd85ff0629cd2c5141027fc1c8bb6cde9c:
>
> Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2017-11-21 05:56:12 -1000)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/for-linus-timers-conversion-final-v4.15-rc1
>
> for you to fetch changes up to c10d4a0af0eb5d549193de2593791d1dd29895db:
>
> treewide: Remove TIMER_FUNC_TYPE cast (2017-11-21 15:57:16 -0800)
Brown paper bag update:
I just refreshed this tag with 1 more fix to s390's removal of
TIMER_DATA_TYPE. Tag remains the same. The SHA of the last commit is
now:
841b86f3289d ("treewide: Remove TIMER_FUNC_TYPE and TIMER_DATA_TYPE casts")
Thanks!
-Kees
>
> ----------------------------------------------------------------
> - final batch of "non trivial" timer conversions (multi-tree dependencies,
> things Coccinelle couldn't handle, etc).
> - treewide conversions via Coccinelle, in 4 steps:
> - DEFINE_TIMER() functions converted to struct timer_list * argument
> - init_timer() -> setup_timer()
> - setup_timer() -> timer_setup()
> - setup_timer() -> timer_setup() (with a single embedded structure)
> - deprecated timer API removals (init_timer(), setup_*timer())
> - finalization of new API (remove global casts)
>
> ----------------------------------------------------------------
> Kees Cook (22):
> drivers/firmware: psci: Convert timers to use timer_setup()
> usb: usbatm: Convert timers to use timer_setup()
> drm/i915/selftests: Convert timers to use timer_setup()
> net/atm/mpc: Avoid open-coded assignment of timer callback function
> block/laptop_mode: Convert timers to use timer_setup()
> drm/vc4: Convert timers to use timer_setup()
> drivers/net: cris: Convert timers to use timer_setup()
> lightnvm: Convert timers to use timer_setup()
> s390: cmm: Convert timers to use timer_setup()
> treewide: Switch DEFINE_TIMER callbacks to struct timer_list *
> treewide: init_timer() -> setup_timer()
> treewide: setup_timer() -> timer_setup()
> treewide: setup_timer() -> timer_setup() (2 field)
> timer: Remove init_timer() interface
> timer: Remove setup_*timer() interface
> Coccinelle: Remove setup_timer.cocci
> timer: Pass timer_list pointer to callbacks unconditionally
> timer: Switch callback prototype to take struct timer_list * argument
> timer: Remove unused data arguments from macros
> timer: Pass function down to initialization routines
> timer: Remove redundant __setup_timer*() macros
> treewide: Remove TIMER_FUNC_TYPE cast
>
> Documentation/core-api/local_ops.rst | 10 +-
> arch/alpha/kernel/srmcons.c | 7 +-
> arch/arm/mach-iop32x/n2100.c | 5 +-
> arch/arm/mach-ixp4xx/dsmg600-setup.c | 4 +-
> arch/arm/mach-ixp4xx/nas100d-setup.c | 4 +-
> arch/arm/mach-orion5x/db88f5281-setup.c | 4 +-
> arch/blackfin/kernel/nmi.c | 5 +-
> arch/m68k/amiga/amisound.c | 4 +-
> arch/m68k/mac/macboing.c | 4 +-
> arch/mips/lasat/picvue_proc.c | 4 +-
> arch/mips/mti-malta/malta-display.c | 4 +-
> arch/parisc/kernel/pdc_cons.c | 4 +-
> arch/powerpc/kernel/tau_6xx.c | 4 +-
> arch/powerpc/kvm/booke.c | 7 +-
> arch/powerpc/oprofile/op_model_cell.c | 8 +-
> arch/powerpc/platforms/cell/spufs/sched.c | 8 +-
> arch/powerpc/platforms/powermac/low_i2c.c | 6 +-
> arch/s390/kernel/time.c | 4 +-
> arch/s390/mm/cmm.c | 8 +-
> arch/sh/drivers/heartbeat.c | 6 +-
> arch/sh/drivers/pci/common.c | 16 +-
> arch/sh/drivers/push-switch.c | 9 +-
> block/blk-core.c | 10 +-
> block/blk-stat.c | 6 +-
> block/blk-throttle.c | 9 +-
> drivers/atm/ambassador.c | 9 +-
> drivers/atm/firestream.c | 8 +-
> drivers/atm/horizon.c | 8 +-
> drivers/atm/idt77105.c | 8 +-
> drivers/atm/idt77252.c | 6 +-
> drivers/atm/iphase.c | 4 +-
> drivers/atm/lanai.c | 8 +-
> drivers/atm/nicstar.c | 8 +-
> drivers/base/power/wakeup.c | 2 +-
> drivers/block/DAC960.c | 9 +-
> drivers/block/DAC960.h | 2 +-
> drivers/block/aoe/aoecmd.c | 2 +-
> drivers/block/ataflop.c | 16 +-
> drivers/block/rsxx/cregs.c | 7 +-
> drivers/block/rsxx/dma.c | 7 +-
> drivers/block/skd_main.c | 6 +-
> drivers/block/sunvdc.c | 9 +-
> drivers/block/swim3.c | 2 +-
> drivers/block/umem.c | 5 +-
> drivers/block/xsysace.c | 6 +-
> drivers/char/dtlk.c | 4 +-
> drivers/char/hangcheck-timer.c | 4 +-
> drivers/char/ipmi/bt-bmc.c | 7 +-
> drivers/char/ipmi/ipmi_msghandler.c | 4 +-
> drivers/char/ipmi/ipmi_si_intf.c | 6 +-
> drivers/char/ipmi/ipmi_ssif.c | 7 +-
> drivers/char/nwbutton.c | 4 +-
> drivers/char/nwbutton.h | 2 +-
> drivers/char/rtc.c | 4 +-
> drivers/char/tpm/tpm-dev-common.c | 7 +-
> drivers/firmware/psci_checker.c | 4 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 8 +-
> drivers/gpu/drm/drm_vblank.c | 11 +-
> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 6 +-
> drivers/gpu/drm/i2c/tda998x_drv.c | 7 +-
> drivers/gpu/drm/i915/selftests/lib_sw_fence.c | 6 +-
> drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 7 +-
> drivers/gpu/drm/msm/msm_gpu.c | 7 +-
> drivers/gpu/drm/omapdrm/dss/dsi.c | 6 +-
> drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 6 +-
> drivers/gpu/drm/vc4/vc4_bo.c | 9 +-
> drivers/gpu/drm/vc4/vc4_gem.c | 10 +-
> drivers/gpu/drm/vgem/vgem_fence.c | 6 +-
> drivers/gpu/drm/via/via_dmablit.c | 7 +-
> drivers/hid/hid-appleir.c | 7 +-
> drivers/hid/hid-prodikeys.c | 7 +-
> drivers/hid/hid-wiimote-core.c | 6 +-
> drivers/iio/common/ssp_sensors/ssp_dev.c | 6 +-
> drivers/infiniband/hw/mlx5/mr.c | 6 +-
> drivers/infiniband/hw/mthca/mthca_catas.c | 8 +-
> drivers/infiniband/hw/nes/nes_verbs.c | 2 +-
> drivers/input/gameport/gameport.c | 7 +-
> drivers/input/input.c | 2 +-
> drivers/input/joystick/db9.c | 6 +-
> drivers/input/joystick/gamecon.c | 6 +-
> drivers/input/joystick/turbografx.c | 6 +-
> drivers/input/touchscreen/s3c2410_ts.c | 2 +-
> drivers/iommu/iova.c | 8 +-
> drivers/isdn/capi/capidrv.c | 6 +-
> drivers/isdn/divert/isdn_divert.c | 9 +-
> drivers/isdn/hardware/eicon/divasi.c | 9 +-
> drivers/isdn/hardware/mISDN/hfcmulti.c | 8 +-
> drivers/isdn/hardware/mISDN/hfcpci.c | 10 +-
> drivers/isdn/hardware/mISDN/mISDNisar.c | 10 +-
> drivers/isdn/i4l/isdn_common.c | 5 +-
> drivers/isdn/i4l/isdn_net.c | 9 +-
> drivers/isdn/i4l/isdn_ppp.c | 9 +-
> drivers/isdn/i4l/isdn_tty.c | 7 +-
> drivers/lightnvm/pblk-core.c | 4 +-
> drivers/lightnvm/pblk-gc.c | 6 +-
> drivers/lightnvm/pblk-init.c | 2 +-
> drivers/lightnvm/pblk-rl.c | 6 +-
> drivers/lightnvm/pblk.h | 2 +-
> drivers/lightnvm/rrpc.c | 6 +-
> drivers/media/common/saa7146/saa7146_vbi.c | 2 +-
> drivers/media/platform/fsl-viu.c | 7 +-
> drivers/media/platform/s5p-mfc/s5p_mfc.c | 8 +-
> .../media/platform/sti/c8sectpfe/c8sectpfe-core.c | 7 +-
> drivers/media/platform/vim2m.c | 6 +-
> drivers/media/usb/au0828/au0828-dvb.c | 8 +-
> drivers/media/usb/au0828/au0828-video.c | 14 +-
> drivers/memstick/core/ms_block.c | 7 +-
> drivers/mfd/rtsx_usb.c | 6 +-
> drivers/mmc/core/host.c | 6 +-
> drivers/mtd/sm_ftl.c | 6 +-
> drivers/net/caif/caif_hsi.c | 21 +-
> drivers/net/cris/eth_v10.c | 36 ++-
> drivers/net/dsa/mv88e6xxx/phy.c | 7 +-
> drivers/net/eql.c | 6 +-
> drivers/net/ethernet/adi/bfin_mac.c | 9 +-
> drivers/net/ethernet/agere/et131x.c | 7 +-
> drivers/net/ethernet/amazon/ena/ena_netdev.c | 7 +-
> drivers/net/ethernet/aquantia/atlantic/aq_nic.c | 14 +-
> drivers/net/ethernet/atheros/atl1c/atl1c_main.c | 8 +-
> drivers/net/ethernet/atheros/atl1e/atl1e_main.c | 8 +-
> drivers/net/ethernet/atheros/atlx/atl1.c | 8 +-
> drivers/net/ethernet/atheros/atlx/atl2.c | 15 +-
> drivers/net/ethernet/broadcom/b44.c | 6 +-
> drivers/net/ethernet/broadcom/bnx2.c | 6 +-
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 6 +-
> drivers/net/ethernet/broadcom/bnxt/bnxt.c | 6 +-
> drivers/net/ethernet/broadcom/tg3.c | 6 +-
> drivers/net/ethernet/cisco/enic/enic_clsf.c | 4 +-
> drivers/net/ethernet/cisco/enic/enic_clsf.h | 5 +-
> drivers/net/ethernet/cisco/enic/enic_main.c | 7 +-
> drivers/net/ethernet/marvell/mv643xx_eth.c | 13 +-
> drivers/net/ethernet/marvell/pxa168_eth.c | 7 +-
> drivers/net/ethernet/marvell/skge.c | 6 +-
> drivers/net/ethernet/marvell/sky2.c | 6 +-
> drivers/net/ethernet/myricom/myri10ge/myri10ge.c | 7 +-
> .../net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 8 +-
> drivers/net/ethernet/pasemi/pasemi_mac.c | 7 +-
> drivers/net/ethernet/qlogic/qla3xxx.c | 6 +-
> drivers/net/ethernet/rocker/rocker_ofdpa.c | 7 +-
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 15 +-
> drivers/net/ethernet/synopsys/dwc-xlgmac-net.c | 7 +-
> drivers/net/ethernet/ti/cpsw_ale.c | 6 +-
> drivers/net/ethernet/ti/netcp_ethss.c | 7 +-
> drivers/net/ethernet/ti/tlan.c | 6 +-
> drivers/net/ethernet/toshiba/spider_net.c | 16 +-
> drivers/net/hamradio/scc.c | 8 +-
> drivers/net/slip/slip.c | 16 +-
> drivers/net/tun.c | 8 +-
> drivers/net/wan/hdlc_ppp.c | 6 +-
> drivers/net/wireless/atmel/at76c50x-usb.c | 4 +-
> .../wireless/broadcom/brcm80211/brcmfmac/btcoex.c | 6 +-
> .../broadcom/brcm80211/brcmfmac/cfg80211.c | 7 +-
> .../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 7 +-
> drivers/net/wireless/intel/iwlwifi/dvm/main.c | 14 +-
> drivers/net/wireless/intel/iwlwifi/dvm/tt.c | 18 +-
> drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 7 +-
> drivers/net/wireless/intersil/hostap/hostap_ap.c | 8 +-
> drivers/net/wireless/intersil/hostap/hostap_hw.c | 17 +-
> .../net/wireless/intersil/orinoco/orinoco_usb.c | 6 +-
> drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 2 +-
> drivers/net/wireless/quantenna/qtnfmac/core.c | 2 +-
> drivers/net/wireless/ray_cs.c | 12 +-
> drivers/net/wireless/ti/wlcore/main.c | 7 +-
> drivers/net/xen-netfront.c | 7 +-
> drivers/nfc/nfcmrvl/fw_dnld.c | 7 +-
> drivers/nfc/pn533/pn533.c | 8 +-
> drivers/nfc/st-nci/ndlc.c | 17 +-
> drivers/nfc/st-nci/se.c | 19 +-
> drivers/nfc/st21nfca/se.c | 19 +-
> drivers/ntb/test/ntb_pingpong.c | 8 +-
> drivers/platform/x86/sony-laptop.c | 4 +-
> drivers/pps/clients/pps-ktimer.c | 4 +-
> drivers/rtc/rtc-dev.c | 6 +-
> drivers/s390/block/dasd.c | 20 +-
> drivers/s390/char/sclp.c | 2 +-
> drivers/s390/net/fsm.c | 11 +-
> drivers/s390/scsi/zfcp_fsf.c | 4 +-
> drivers/scsi/aic94xx/aic94xx_hwi.c | 2 +-
> drivers/scsi/aic94xx/aic94xx_tmf.c | 2 +-
> drivers/scsi/arcmsr/arcmsr_hba.c | 14 +-
> drivers/scsi/arm/fas216.c | 8 +-
> drivers/scsi/be2iscsi/be_main.c | 4 +-
> drivers/scsi/bfa/bfad.c | 8 +-
> drivers/scsi/bfa/bfad_drv.h | 2 +-
> drivers/scsi/bnx2fc/bnx2fc_tgt.c | 16 +-
> drivers/scsi/cxgbi/cxgb3i/cxgb3i.c | 4 +-
> drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 4 +-
> drivers/scsi/esas2r/esas2r_main.c | 10 +-
> drivers/scsi/fcoe/fcoe_ctlr.c | 8 +-
> drivers/scsi/fnic/fnic_main.c | 14 +-
> drivers/scsi/hisi_sas/hisi_sas_main.c | 4 +-
> drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 6 +-
> drivers/scsi/ipr.c | 8 +-
> drivers/scsi/libfc/fc_fcp.c | 6 +-
> drivers/scsi/libsas/sas_expander.c | 2 +-
> drivers/scsi/libsas/sas_scsi_host.c | 2 +-
> drivers/scsi/mvsas/mv_sas.c | 4 +-
> drivers/scsi/ncr53c8xx.c | 8 +-
> drivers/scsi/pm8001/pm8001_sas.c | 4 +-
> drivers/scsi/pmcraid.c | 10 +-
> drivers/scsi/sym53c8xx_2/sym_glue.c | 8 +-
> drivers/staging/greybus/operation.c | 7 +-
> drivers/staging/irda/include/net/irda/timer.h | 2 +-
> drivers/staging/lustre/lnet/lnet/net_fault.c | 6 +-
> drivers/staging/lustre/lustre/ptlrpc/service.c | 9 +-
> drivers/staging/media/imx/imx-ic-prpencvf.c | 7 +-
> drivers/staging/media/imx/imx-media-csi.c | 7 +-
> drivers/staging/most/hdm-usb/hdm_usb.c | 7 +-
> .../staging/rtl8192u/ieee80211/ieee80211_softmac.c | 16 +-
> drivers/staging/rtl8712/recv_linux.c | 9 +-
> drivers/staging/rtl8712/rtl8712_led.c | 9 +-
> drivers/staging/speakup/main.c | 4 +-
> drivers/staging/speakup/synth.c | 2 +-
> drivers/staging/unisys/visorbus/visorbus_main.c | 6 +-
> drivers/staging/unisys/visornic/visornic_main.c | 8 +-
> drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 8 +-
> drivers/target/target_core_user.c | 7 +-
> drivers/tty/cyclades.c | 4 +-
> drivers/tty/ipwireless/hardware.c | 11 +-
> drivers/tty/isicom.c | 4 +-
> drivers/tty/moxa.c | 4 +-
> drivers/tty/n_gsm.c | 12 +-
> drivers/tty/n_r3964.c | 8 +-
> drivers/tty/rocket.c | 4 +-
> drivers/tty/serial/8250/8250_core.c | 4 +-
> drivers/tty/serial/crisv10.c | 4 +-
> drivers/tty/serial/fsl_lpuart.c | 7 +-
> drivers/tty/serial/ifx6x60.c | 7 +-
> drivers/tty/serial/imx.c | 6 +-
> drivers/tty/serial/kgdb_nmi.c | 6 +-
> drivers/tty/serial/max3100.c | 7 +-
> drivers/tty/serial/mux.c | 4 +-
> drivers/tty/serial/pnx8xxx_uart.c | 7 +-
> drivers/tty/serial/sa1100.c | 7 +-
> drivers/tty/serial/sh-sci.c | 16 +-
> drivers/tty/serial/sn_console.c | 6 +-
> drivers/tty/synclink.c | 8 +-
> drivers/tty/synclink_gt.c | 16 +-
> drivers/tty/synclinkmp.c | 17 +-
> drivers/tty/vt/keyboard.c | 2 +-
> drivers/tty/vt/vt.c | 4 +-
> drivers/usb/atm/cxacru.c | 23 +-
> drivers/usb/atm/speedtch.c | 16 +-
> drivers/usb/atm/usbatm.c | 10 +-
> drivers/usb/core/hcd.c | 8 +-
> drivers/usb/dwc2/hcd.c | 7 +-
> drivers/usb/dwc2/hcd_queue.c | 7 +-
> drivers/usb/gadget/udc/at91_udc.c | 7 +-
> drivers/usb/gadget/udc/dummy_hcd.c | 8 +-
> drivers/usb/gadget/udc/m66592-udc.c | 6 +-
> drivers/usb/gadget/udc/omap_udc.c | 8 +-
> drivers/usb/gadget/udc/pxa25x_udc.c | 6 +-
> drivers/usb/gadget/udc/r8a66597-udc.c | 6 +-
> drivers/usb/host/ohci-hcd.c | 9 +-
> drivers/usb/host/oxu210hp-hcd.c | 6 +-
> drivers/usb/host/r8a66597-hcd.c | 7 +-
> drivers/usb/host/sl811-hcd.c | 6 +-
> drivers/usb/host/uhci-hcd.c | 3 +-
> drivers/usb/host/uhci-q.c | 4 +-
> drivers/usb/host/xhci.c | 8 +-
> drivers/usb/serial/mos7840.c | 15 +-
> drivers/usb/storage/realtek_cr.c | 7 +-
> drivers/uwb/drp.c | 6 +-
> drivers/uwb/neh.c | 8 +-
> drivers/uwb/rsv.c | 15 +-
> drivers/uwb/uwb-internal.h | 2 +-
> drivers/watchdog/alim7101_wdt.c | 4 +-
> drivers/watchdog/at91sam9_wdt.c | 6 +-
> drivers/watchdog/bcm47xx_wdt.c | 9 +-
> drivers/watchdog/bcm63xx_wdt.c | 4 +-
> drivers/watchdog/cpu5wdt.c | 4 +-
> drivers/watchdog/machzwd.c | 4 +-
> drivers/watchdog/mixcomwd.c | 4 +-
> drivers/watchdog/mpc8xxx_wdt.c | 7 +-
> drivers/watchdog/mtx-1_wdt.c | 4 +-
> drivers/watchdog/nuc900_wdt.c | 4 +-
> drivers/watchdog/pcwd.c | 4 +-
> drivers/watchdog/pika_wdt.c | 4 +-
> drivers/watchdog/rdc321x_wdt.c | 4 +-
> drivers/watchdog/sbc60xxwdt.c | 4 +-
> drivers/watchdog/sc520_wdt.c | 4 +-
> drivers/watchdog/shwdt.c | 6 +-
> drivers/watchdog/via_wdt.c | 4 +-
> drivers/watchdog/w83877f_wdt.c | 4 +-
> drivers/xen/grant-table.c | 4 +-
> fs/ocfs2/cluster/tcp.c | 9 +-
> fs/pstore/platform.c | 4 +-
> include/linux/kthread.h | 10 +-
> include/linux/timer.h | 120 +++------
> include/linux/workqueue.h | 17 +-
> include/linux/writeback.h | 2 +-
> kernel/irq/spurious.c | 4 +-
> kernel/kthread.c | 2 +-
> kernel/padata.c | 6 +-
> kernel/time/clocksource.c | 5 +-
> kernel/time/timer.c | 40 +--
> kernel/workqueue.c | 2 +-
> lib/random32.c | 4 +-
> mm/page-writeback.c | 7 +-
> net/802/garp.c | 6 +-
> net/802/mrp.c | 13 +-
> net/appletalk/aarp.c | 4 +-
> net/appletalk/ddp.c | 7 +-
> net/atm/lec.c | 6 +-
> net/atm/mpc.c | 3 +-
> net/batman-adv/tp_meter.c | 14 +-
> net/bluetooth/hidp/core.c | 7 +-
> net/bluetooth/rfcomm/core.c | 12 +-
> net/bluetooth/sco.c | 6 +-
> net/can/proc.c | 4 +-
> net/core/drop_monitor.c | 7 +-
> net/core/gen_estimator.c | 6 +-
> net/core/neighbour.c | 14 +-
> net/decnet/dn_route.c | 8 +-
> net/decnet/dn_timer.c | 8 +-
> net/ipv4/igmp.c | 20 +-
> net/ipv4/ipmr.c | 9 +-
> net/ipv6/addrconf.c | 9 +-
> net/ipv6/ip6_fib.c | 10 +-
> net/ipv6/ip6_flowlabel.c | 4 +-
> net/ipv6/ip6mr.c | 9 +-
> net/ipv6/mcast.c | 33 ++-
> net/lapb/lapb_timer.c | 4 +-
> net/ncsi/ncsi-manage.c | 15 +-
> net/netfilter/nf_conntrack_expect.c | 7 +-
> net/netfilter/nfnetlink_log.c | 8 +-
> net/netfilter/xt_IDLETIMER.c | 7 +-
> net/netfilter/xt_LED.c | 8 +-
> net/netrom/af_netrom.c | 2 +-
> net/netrom/nr_loopback.c | 4 +-
> net/netrom/nr_timer.c | 2 +-
> net/nfc/nci/core.c | 14 +-
> net/rose/rose_link.c | 4 +-
> net/rose/rose_timer.c | 12 +-
> net/rxrpc/call_object.c | 7 +-
> net/sunrpc/svc_xprt.c | 2 +-
> net/wireless/lib80211.c | 11 +-
> net/x25/af_x25.c | 2 +-
> net/x25/x25_link.c | 8 +-
> net/x25/x25_timer.c | 2 +-
> net/xfrm/xfrm_state.c | 9 +-
> scripts/coccinelle/api/setup_timer.cocci | 277 ---------------------
> security/keys/gc.c | 4 +-
> sound/usb/line6/driver.c | 2 +-
> 344 files changed, 1212 insertions(+), 1705 deletions(-)
> delete mode 100644 scripts/coccinelle/api/setup_timer.cocci
>
> --
> Kees Cook
> Pixel Security
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] seccomp updates for next
@ 2017-11-29 0:38 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-11-29 0:38 UTC (permalink / raw)
To: James Morris; +Cc: linux-kernel, linux-security-module, Tycho Andersen
Hi James,
Please pull these seccomp changes for next. This implements an interface
for examining seccomp filter metadata when using CRIU.
Thanks!
-Kees
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-next
for you to fetch changes up to 26500475ac1b499d8636ff281311d633909f5d20:
ptrace, seccomp: add support for retrieving seccomp metadata (2017-11-28 15:41:01 -0800)
----------------------------------------------------------------
add support for retrieving seccomp filter metadata (Tycho Andersen)
----------------------------------------------------------------
Tycho Andersen (2):
seccomp: hoist out filter resolving logic
ptrace, seccomp: add support for retrieving seccomp metadata
include/linux/seccomp.h | 8 ++++
include/uapi/linux/ptrace.h | 6 +++
kernel/ptrace.c | 4 ++
kernel/seccomp.c | 106 +++++++++++++++++++++++++++++++-------------
4 files changed, 94 insertions(+), 30 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] hash addresses printed with %p
@ 2017-11-29 21:31 92% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-11-29 21:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Tobin C. Harding, LKML
On Wed, Nov 29, 2017 at 11:39 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Wed, Nov 29, 2017 at 11:22 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> What I didn't realize until after pulling this and testing, is that it
>> completely breaks '%pK'.
>>
>> We've marked various sensitive pointers with %pK, but that is now
>> _less_ secure than %p is, since it doesn't do the hashing because of
>> how you refactored the %pK code out of 'pointer()' into its own
>> function.
>>
>> So now %pK ends up using the plain "number()" function. Reading
>> through the series I hadn't noticed that the refactoring ended up
>> messing with that.
>>
>> I'll fix it up somehow.
>
> I ended up just doing this:
>
> case 'K':
> + if (!kptr_restrict)
> + break;
> return restricted_pointer(buf, end, ptr, spec);
>
> which basically says that "if kptr_restrict isn't set, %pK is the same as %p".
>
> Now, I feel that we should probably get rid of 'restricted_pointer()'
> entirely, since now the regular '%p' is arguably safer than '%pK' is,
> but I also didn't want to mess with the case that I have never used
> and that most distros don't seem to set.
kptr_restrict=0 is now much safer, yes (i.e. %pK becomes hashed %p).
Strictly speaking, kptr_restrict > 0 is "better" than hashed %p, in
that it only says "0".
> Alternatively, we might make the 'K' behavior of clearing the pointer
> be in addition to the other flags, so that you could do '%pxK' and get
> the old %pK behavior. But since I am not a huge fan of %pK to begin
> with, I can't find it in myself to care too much.
>
> So I'll leave that for Kees & co to decide on. Comments?
I'm not hugely attached to %pK, but retaining its ability to zero out
the result would be nice.
(If we in the future we have a toggle for %p that switches it from
hashing to zeroing, then we could entirely drop %pK.)
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] hash addresses printed with %p
@ 2017-12-01 16:33 92% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2017-12-01 16:33 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Ard Biesheuvel, Linus Torvalds, Tobin C. Harding, Matt Fleming,
LKML, linux-efi
On Fri, Dec 1, 2017 at 7:34 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> And isn't there a specific %p modifier you should use for a kernel
> pointer. I've lost the thread here for what should, or should not, be
> done for kernel pointers these days based on the long email discussion.
Current implementation to bypass the hashing is %px. (Though perhaps
all %px usage should include a comment with a justification?)
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] parisc architecture fixes for 4.15-rc7
@ 2018-01-09 23:03 92% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-01-09 23:03 UTC (permalink / raw)
To: Helge Deller, Linus Torvalds
Cc: LKML, linux-parisc, James Bottomley, John David Anglin,
Richard Henderson, Laura Abbott
On Sun, Jan 7, 2018 at 8:21 AM, Helge Deller <deller@gmx.de> wrote:
> Hi Linus,
>
> please pull a few fixes for the parisc architecture from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-4.15-3
>
> The fixes are:
> - Many small fixes to show the real physical addresses of devices instead of
> hashed addresses.
>
> - One important fix to unbreak 32-bit SMP support: We forgot to 16-byte align
> the spinlocks in the assembler code.
>
> - Qemu support: The host will get a chance to sleep when the parisc guest is
> idle. We use the same mechanism as the power architecture by overlaying the
> "or %r10,%r10,%r10" instruction which is simply a nop on real hardware.
>
> Thanks,
> Helge
>
> ----------------------------------------------------------------
> Helge Deller (6):
> parisc: Show unhashed hardware inventory
> parisc: Show unhashed EISA EEPROM address
These looks like a physical addresses, yes.
> parisc: Show initial kernel memory layout unhashed
> parisc: Show unhashed HPA of Dino chip
But these are virtual addresses and should be just removed, not
switched to %px. They're not physical addresses that I can see, e.g.
"dino_dev" is clearly being used as an in-memory structure, and the
kernel layout literally says "virtual kernel memory layout".
Especially the kernel memory layout going to dmesg should be removed.
That kind of thing has been entirely removed from other architectures
(or will be soon[1]). See commit adb1fe9ae2ee ("mm/page_alloc: Remove
kernel address exposure in free_reserved_area()"). (Also note that
hiding behind CONFIG_DEBUG_KERNEL is not sufficient: most distros
build with that config.)
-Kees
[1] https://www.spinics.net/lists/arm-kernel/msg624390.html
> parisc: Fix alignment of pa_tlb_lock in assembly on 32-bit SMP kernel
> parisc: qemu idle sleep support
>
> arch/parisc/include/asm/ldcw.h | 2 ++
> arch/parisc/kernel/drivers.c | 2 +-
> arch/parisc/kernel/entry.S | 13 +++++++++++--
> arch/parisc/kernel/pacache.S | 9 +++++++--
> arch/parisc/kernel/process.c | 39 +++++++++++++++++++++++++++++++++++++++
> arch/parisc/mm/init.c | 10 +++++-----
> drivers/parisc/dino.c | 10 +++++-----
> drivers/parisc/eisa_eeprom.c | 2 +-
> 8 files changed, 71 insertions(+), 16 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] hardened usercopy whitelisting for v4.16-rc1
@ 2018-01-29 10:54 61% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-01-29 10:54 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Christian Borntraeger, Christoffer Dall,
Christoph Lameter, Dave Kleikamp, Jan Kara, Luis de Bethencourt,
Marc Zyngier, Rik van Riel, David Windsor, Paolo Bonzini,
Matthew Garrett
Hi Linus,
Please pull these hardened usercopy changes for v4.16-rc1. This is very
close to what I sent for v4.15, though now it has a couple more Acks,
I reorganized the WARN-by-default to be earlier in the series where
hopefully it stands out better, and I improved reporting (while also
dropping the nearly meaningless %p usage). The bulk of this series
has been living happily in linux-next for almost two devel cycles now,
so my impression is that it's baked well enough for prime-time.
One merge conflict with net (sctp) appeared about 3 weeks ago, which
should prefer the usercopy version (since it uses a constant size for
the copy). Noted here: https://lkml.org/lkml/2018/1/11/757
Thanks!
-Kees
The following changes since commit ae64f9bd1d3621b5e60d7363bc20afb46aede215:
Linux 4.15-rc2 (2017-12-03 11:01:47 -0500)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/usercopy-v4.16-rc1
for you to fetch changes up to e47e311843dece8073146f3606871280ee9beb87:
lkdtm: Update usercopy tests for whitelisting (2018-01-15 12:08:09 -0800)
----------------------------------------------------------------
Currently, hardened usercopy performs dynamic bounds checking on slab
cache objects. This is good, but still leaves a lot of kernel memory
available to be copied to/from userspace in the face of bugs. To further
restrict what memory is available for copying, this creates a way to
whitelist specific areas of a given slab cache object for copying to/from
userspace, allowing much finer granularity of access control. Slab caches
that are never exposed to userspace can declare no whitelist for their
objects, thereby keeping them unavailable to userspace via dynamic copy
operations. (Note, an implicit form of whitelisting is the use of constant
sizes in usercopy operations and get_user()/put_user(); these bypass all
hardened usercopy checks since these sizes cannot change at runtime.)
This new check is WARN-by-default, so any mistakes can be found over the
next several releases without breaking anyone's system.
The series has roughly the following sections:
- remove %p and improve reporting with offset
- prepare infrastructure and whitelist kmalloc
- update VFS subsystem with whitelists
- update SCSI subsystem with whitelists
- update network subsystem with whitelists
- update process memory with whitelists
- update per-architecture thread_struct with whitelists
- update KVM with whitelists and fix ioctl bug
- mark all other allocations as not whitelisted
- update lkdtm for more sensible test overage
----------------------------------------------------------------
David Windsor (22):
usercopy: Prepare for usercopy whitelisting
usercopy: Mark kmalloc caches as usercopy caches
dcache: Define usercopy region in dentry_cache slab cache
vfs: Define usercopy region in names_cache slab caches
vfs: Copy struct mount.mnt_id to userspace using put_user()
ext4: Define usercopy region in ext4_inode_cache slab cache
ext2: Define usercopy region in ext2_inode_cache slab cache
jfs: Define usercopy region in jfs_ip slab cache
befs: Define usercopy region in befs_inode_cache slab cache
exofs: Define usercopy region in exofs_inode_cache slab cache
orangefs: Define usercopy region in orangefs_inode_cache slab cache
ufs: Define usercopy region in ufs_inode_cache slab cache
vxfs: Define usercopy region in vxfs_inode slab cache
cifs: Define usercopy region in cifs_request slab cache
scsi: Define usercopy region in scsi_sense_cache slab cache
net: Define usercopy region in struct proto slab cache
ip: Define usercopy region in IP proto slab cache
caif: Define usercopy region in caif proto slab cache
sctp: Define usercopy region in SCTP proto slab cache
sctp: Copy struct sctp_sock.autoclose to userspace using put_user()
fork: Define usercopy region in mm_struct slab caches
fork: Define usercopy region in thread_stack slab caches
Kees Cook (14):
usercopy: Remove pointer from overflow report
usercopy: Enhance and rename report_usercopy()
usercopy: Include offset in hardened usercopy report
lkdtm/usercopy: Adjust test to include an offset to check reporting
stddef.h: Introduce sizeof_field()
usercopy: WARN() on slab cache usercopy region violations
usercopy: Allow strict enforcement of whitelists
net: Restrict unwhitelisted proto caches to size 0
fork: Provide usercopy whitelisting for task_struct
x86: Implement thread_struct whitelist for hardened usercopy
arm64: Implement thread_struct whitelist for hardened usercopy
arm: Implement thread_struct whitelist for hardened usercopy
usercopy: Restrict non-usercopy caches to size 0
lkdtm: Update usercopy tests for whitelisting
Paolo Bonzini (2):
kvm: whitelist struct kvm_vcpu_arch
kvm: x86: fix KVM_XEN_HVM_CONFIG ioctl
arch/Kconfig | 11 +++
arch/arm/Kconfig | 1 +
arch/arm/include/asm/processor.h | 10 +++
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/processor.h | 10 +++
arch/x86/Kconfig | 1 +
arch/x86/include/asm/processor.h | 8 +++
arch/x86/kvm/x86.c | 7 +-
drivers/misc/lkdtm.h | 4 +-
drivers/misc/lkdtm_core.c | 4 +-
drivers/misc/lkdtm_usercopy.c | 101 ++++++++++++++++------------
drivers/scsi/scsi_lib.c | 9 +--
fs/befs/linuxvfs.c | 14 ++--
fs/cifs/cifsfs.c | 10 +--
fs/dcache.c | 9 +--
fs/exofs/super.c | 7 +-
fs/ext2/super.c | 12 ++--
fs/ext4/super.c | 12 ++--
fs/fhandle.c | 3 +-
fs/freevxfs/vxfs_super.c | 8 ++-
fs/jfs/super.c | 8 ++-
fs/orangefs/super.c | 15 +++--
fs/ufs/super.c | 13 ++--
include/linux/sched/task.h | 14 ++++
include/linux/slab.h | 41 ++++++++----
include/linux/slab_def.h | 3 +
include/linux/slub_def.h | 3 +
include/linux/stddef.h | 10 ++-
include/linux/uaccess.h | 8 +++
include/net/sctp/structs.h | 9 ++-
include/net/sock.h | 2 +
kernel/fork.c | 31 +++++++--
mm/slab.c | 36 +++++++---
mm/slab.h | 8 ++-
mm/slab_common.c | 62 ++++++++++++++---
mm/slub.c | 49 ++++++++++----
mm/usercopy.c | 133 +++++++++++++++++++++----------------
net/caif/caif_socket.c | 2 +
net/core/sock.c | 4 +-
net/ipv4/raw.c | 2 +
net/ipv6/raw.c | 2 +
net/sctp/socket.c | 10 ++-
security/Kconfig | 14 ++++
tools/objtool/check.c | 1 +
virt/kvm/kvm_main.c | 8 ++-
45 files changed, 515 insertions(+), 215 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 61%]
* [GIT PULL] pstore update for v4.16-rc1
@ 2018-01-29 10:59 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-01-29 10:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Yang Shi
Hi Linus,
Please pull this tiny pstore change for v4.16-rc1. Only a header cleanup
this release; nice and quiet. :)
Thanks!
-Kees
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/pstore-v4.16-rc1
for you to fetch changes up to a99f41a1b4412a0f27cc0b287ea34b168da750f1:
fs: pstore: remove unused hardirq.h (2017-11-28 16:39:09 -0800)
----------------------------------------------------------------
- clean up hardirq header usage (Yang Shi)
----------------------------------------------------------------
Yang Shi (1):
fs: pstore: remove unused hardirq.h
fs/pstore/platform.c | 1 -
1 file changed, 1 deletion(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] gcc-plugins updates for v4.16-rc1
@ 2018-02-07 3:00 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-02-07 3:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Kees Cook, Valdis Kletnieks
Hi Linus,
Please pull these gcc-plugins changes for v4.16-rc1. This is a small
set of changes entirely in support of the coming gcc 8 release.
Thanks!
-Kees
The following changes since commit d8a5b80568a9cb66810e75b182018e9edb68e8ff:
Linux 4.15 (2018-01-28 13:20:33 -0800)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/gcc-plugins-v4.16-rc1
for you to fetch changes up to b86729109c5fd0a480300f40608aac68764b5adf:
gcc-plugins: Use dynamic initializers (2018-02-05 17:27:46 -0800)
----------------------------------------------------------------
- update includes for gcc 8 (Valdis Kletnieks)
- update initializers for gcc 8
----------------------------------------------------------------
Kees Cook (1):
gcc-plugins: Use dynamic initializers
Valdis Kletnieks (1):
gcc-plugins: Add include required by GCC release 8
scripts/gcc-plugins/gcc-common.h | 4 ++
scripts/gcc-plugins/latent_entropy_plugin.c | 17 ++----
scripts/gcc-plugins/randomize_layout_plugin.c | 75 ++++++++-------------------
scripts/gcc-plugins/structleak_plugin.c | 19 +++----
4 files changed, 37 insertions(+), 78 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] seccomp updates for v4.16-rc3
@ 2018-02-22 1:04 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-02-22 1:04 UTC (permalink / raw)
To: James Morris
Cc: linux-kernel, Dmitry V. Levin, Eugene Syromiatnikov, Tycho Andersen
Hi James,
Please pull these seccomp changes for v4.16-rc3. These are fixes for the
get_metadata interface that landed during -rc1. While the new selftest
is strictly not a bug fix, I think it's in the same spirit of avoiding
bugs.
Thanks!
-Kees
The following changes since commit 26500475ac1b499d8636ff281311d633909f5d20:
ptrace, seccomp: add support for retrieving seccomp metadata (2017-11-28 15:41:01 -0800)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-v4.16-rc3
for you to fetch changes up to d057dc4e35e16050befa3dda943876dab39cbf80:
seccomp: add a selftest for get_metadata (2018-02-21 16:56:03 -0800)
----------------------------------------------------------------
- Fix seccomp GET_METADATA to deal with fields sizes correctly (Tycho Andersen)
- Add selftest to make sure GET_METADATA doesn't regress (Tycho Andersen)
----------------------------------------------------------------
Tycho Andersen (3):
seccomp, ptrace: switch get_metadata types to arch independent
ptrace, seccomp: tweak get_metadata behavior slightly
seccomp: add a selftest for get_metadata
include/uapi/linux/ptrace.h | 4 +-
kernel/seccomp.c | 6 ++-
tools/testing/selftests/seccomp/seccomp_bpf.c | 61 +++++++++++++++++++++++++++
3 files changed, 67 insertions(+), 4 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] seccomp updates for v4.16-rc3
@ 2018-02-22 1:11 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-02-22 1:11 UTC (permalink / raw)
To: James Morris
Cc: linux-kernel, Dmitry V. Levin, Eugene Syromiatnikov, Tycho Andersen
[resend to updated address ...]
Hi James,
Please pull these seccomp changes for v4.16-rc3. These are fixes for the
get_metadata interface that landed during -rc1. While the new selftest
is strictly not a bug fix, I think it's in the same spirit of avoiding
bugs.
Thanks!
-Kees
The following changes since commit 26500475ac1b499d8636ff281311d633909f5d20:
ptrace, seccomp: add support for retrieving seccomp metadata (2017-11-28 15:41:01 -0800)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-v4.16-rc3
for you to fetch changes up to d057dc4e35e16050befa3dda943876dab39cbf80:
seccomp: add a selftest for get_metadata (2018-02-21 16:56:03 -0800)
----------------------------------------------------------------
- Fix seccomp GET_METADATA to deal with field sizes correctly (Tycho Andersen)
- Add selftest to make sure GET_METADATA doesn't regress (Tycho Andersen)
----------------------------------------------------------------
Tycho Andersen (3):
seccomp, ptrace: switch get_metadata types to arch independent
ptrace, seccomp: tweak get_metadata behavior slightly
seccomp: add a selftest for get_metadata
include/uapi/linux/ptrace.h | 4 +-
kernel/seccomp.c | 6 ++-
tools/testing/selftests/seccomp/seccomp_bpf.c | 61 +++++++++++++++++++++++++++
3 files changed, 67 insertions(+), 4 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] seccomp update for v4.16-rc4
@ 2018-02-27 1:13 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-02-27 1:13 UTC (permalink / raw)
To: James Morris; +Cc: linux-kernel, Kees Cook, Michal Hocko
Hi James,
Please pull this seccomp change for v4.16-rc4. This disables the seccomp
samples when cross compiling. We're seen too many build issues here, so
it's best to just disable it, especially since they're just the samples.
Thanks!
-Kees
The following changes since commit d057dc4e35e16050befa3dda943876dab39cbf80:
seccomp: add a selftest for get_metadata (2018-02-21 16:56:03 -0800)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-v4.16-rc4
for you to fetch changes up to 6275ecbcd3ae3aaf47c3bc1e46343a50f16b2577:
samples/seccomp: do not compile when cross compiled (2018-02-22 09:31:43 -0800)
----------------------------------------------------------------
- do not build samples when cross compiling (Michal Hocko)
----------------------------------------------------------------
Michal Hocko (1):
samples/seccomp: do not compile when cross compiled
samples/seccomp/Makefile | 10 +---------
1 file changed, 1 insertion(+), 9 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] pstore updates for v4.17-rc1
@ 2018-04-02 16:26 90% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-04-02 16:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Arnd Bergmann, Geliang Tang, Kees Cook
Hi Linus,
Please pull these pstore changes for v4.17-rc1. This cycle was almost
entirely improvements to the pstore compression options, noted below.
Thanks!
-Kees
The following changes since commit 91ab883eb21325ad80f3473633f794c78ac87f51:
Linux 4.16-rc2 (2018-02-18 17:29:42 -0800)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/pstore-v4.17-rc1
for you to fetch changes up to 58eb5b6707477ff458db3ee522aac317da719e2a:
pstore: fix crypto dependencies (2018-03-15 10:06:06 -0700)
----------------------------------------------------------------
- Add lz4hc and 842 to pstore compression options (Geliang Tang)
- Refactor to use crypto compression API (Geliang Tang)
- Fix up Kconfig dependencies for compression (Arnd Bergmann)
- Allow for run-time compression selection
- Remove stack VLA usage
----------------------------------------------------------------
Arnd Bergmann (1):
pstore: fix crypto dependencies
Geliang Tang (2):
pstore: Add lz4hc and 842 compression support
pstore: Use crypto compress API
Kees Cook (3):
pstore: Avoid size casts for 842 compression
pstore: Select compression at runtime
pstore/ram: Do not use stack VLA for parity workspace
fs/pstore/Kconfig | 101 +++++++++---
fs/pstore/inode.c | 2 +
fs/pstore/internal.h | 3 +
fs/pstore/platform.c | 372 +++++++++++++++------------------------------
fs/pstore/ram.c | 2 +-
fs/pstore/ram_core.c | 29 +++-
include/linux/pstore_ram.h | 1 +
7 files changed, 226 insertions(+), 284 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 90%]
* Re: [GIT PULL] Kernel lockdown for secure boot
@ 2018-04-03 0:59 86% ` Kees Cook
1 sibling, 0 replies; 200+ results
From: Kees Cook @ 2018-04-03 0:59 UTC (permalink / raw)
To: Andy Lutomirski
Cc: James Morris, David Howells, Alan Cox, Linus Torvalds,
Matthew Garrett, Greg KH, LKML, Justin Forbes, linux-man, joeyli,
linux-security-module, Linux API
On Mon, Apr 2, 2018 at 5:37 PM, Andy Lutomirski <luto@kernel.org> wrote:
> On 03/30/2018 05:46 PM, James Morris wrote:
>>
>> On Sat, 31 Mar 2018, David Howells wrote:
>>
>>> Date: Thu, 26 Oct 2017 17:37:38 +0100
>>>
>>> Hi James,
>>>
>>> Can you pull this patchset into security/next please? It has been in
>>> linux-next since the beginning of March.
>>>
>>> It adds kernel lockdown support for EFI secure boot.
>>
>>
>> Applied to
>> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git
>> next-lockdown and next-testing
>>
>> Are there any known coverage gaps now?
>>
>>
>>
>
> This is an attempt at a review. I'm replying here because I can't find the
> actual relevant patch emails.
>
> Cover letter:
>
>> Here's a set of patches to institute a "locked-down mode" in the
>> kernel and to trigger that mode if the kernel is booted in secure-boot >
>> mode or through the command line.
>
> I think this is seriously problematic in that it's not well defined. It
> sounds like "locked-down mode" means "make me feel good about something".
Naming of this feature has been multi-year bikeshedding, so if we
could just leave the name, that'd be nice.
> For the rest of this review, I'm going to pretend that you actually want two
> features: "try-prevent-root-from-corrupting-the-kernel" and
> "try-to-prevent-root-from-reading-kernel-memory".
That is how I view it, yes. It's about creating a bright line between
uid-0 and ring-0. The most powerful of these distinctions was made
long ago with signed modules. It hasn't been enough, though, since
there have been many ways for uid-0 to read or write kernel memory. My
expectation for this was to reasonably fill all the remaining gaps.
> Also, there should be a justification that allows normal people (i.e. those
> who are not involved in the UEFI signing process) to understand *why* this
> should have anything to do with UEFI. I can very easily see why it would
> make sense for a UEFI authenticated variable to tell the kernel to enable
> one or both of these modes or for there to be an authenticated mechanism for
> the bootloader to tell the kernel to enable it. I do *not* see why the mere
> act of using Secure Boot should have this effect.
>
> In particular, UEFI Secure Boot should *not* enable
> "try-to-prevent-root-from-reading-kernel-memory", which means that, unless
> you actually implement the split, you should drop a bunch of the patches.
>
> In fact, I think the kernel should try to get away from the idea that UEFI
> Secure Boot should imply annoying restrictions. It's really annoying and
> it's never been clear to me that it has a benefit.
FWIW, I've never been a fan of this being UEFI-centric: more than
Secure Boot needs this. For example, Chrome OS's static root of trust
and boot firmware isn't UEFI, but it wants this feature enabled.
Chrome OS would set it on the command line, since the command line is
part of the signed boot image along with the kernel, etc.
> "Restrict /dev/{mem,kmem,port} when the kernel is locked down": this should
> probably split into one restriction for read and one for write.
I think splitting read and write is only useful if there is a use-case
for only blocking one of them. I struggle to imagine allowing write
and blocking read, so really it's the case of wanting to allow read
and disallow write. Is there actually a use-case for this? In all the
"locked down" cases I've seen, both are desired.
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 86%]
* Re: [GIT PULL] Kernel lockdown for secure boot
@ 2018-04-03 18:45 84% ` Kees Cook
0 siblings, 1 reply; 200+ results
From: Kees Cook @ 2018-04-03 18:45 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Matthew Garrett, David Howells, Ard Biesheuvel, James Morris,
Alan Cox, Linus Torvalds, Greg Kroah-Hartman,
Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli,
LSM List, Linux API, linux-efi
On Tue, Apr 3, 2018 at 9:45 AM, Andy Lutomirski <luto@kernel.org> wrote:
> On Tue, Apr 3, 2018 at 9:29 AM, Matthew Garrett <mjg59@google.com> wrote:
>> On Tue, Apr 3, 2018 at 8:11 AM Andy Lutomirski <luto@kernel.org> wrote:
>>> Can you explain that much more clearly? I'm asking why booting via
>>> UEFI Secure Boot should enable lockdown, and I don't see what this has
>>> to do with kexec. And "someone blacklist[ing] your key in the
>>> bootloader" sounds like a political issue, not a technical issue.
>>
>> A kernel that allows users arbitrary access to ring 0 is just an
>> overfeatured bootloader. Why would you want secure boot in that case?
>
> To get a chain of trust. I can provision a system with some public
> keys, stored in UEFI authenticated variables, such that the system
> will only boot a signed image. That signed image, can, in turn, load
> a signed (or hashed or otherwise verfified) kernel and a verified
> initramfs. The initramfs can run a full system from a verified (using
> dm-verity or similar) filesystem, for example. Now it's very hard to
> persistently attack this system. Chromium OS does something very much
> like this, except that it doesn't use UEFI as far as I know. So does
> iOS, and so do some Android versions.
Correct, Chrome OS does not use UEFI, and we still want this patch
series, as it plugs all the known "intentional" escalation paths from
uid-0 to ring-0. Happily, that means all the politics around the UEFI
and Secure Boot case can be ignored, because those issues are specific
to Secure Boot, not the lockdown series. (They are _related_, sure,
but lockdown isn't only about Secure Boot -- it's just that SB is one
of the widely deployed implementations of this kind of
trust-chain-booting-thing. Chrome OS and Android's Verified Boot do
similar things and have the same expectations about the uid-0/ring-0
separation.)
The goal for that bright line on Chrome OS and Android is to stop
attack persistence. We want to know that a reboot onto a new kernel
and OS image will actually result in getting the desired system state,
and that any attack on persistent system data (even for things running
with full root privileges) can't result in using kernel interfaces to
gain kernel control. This isn't expected to be _perfect_, since
nothing is. But it creates a place to work from. The idea that uid-0
is NOT ring-0 is still relatively new, so the existing designs in the
kernel aren't well suited to building that distinction. I view this
series as a solid first step to getting there, though.
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 84%]
* Re: [GIT PULL] Kernel lockdown for secure boot
@ 2018-04-03 19:07 92% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-04-03 19:07 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Matthew Garrett, David Howells, Ard Biesheuvel, James Morris,
Alan Cox, Linus Torvalds, Greg Kroah-Hartman,
Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli,
LSM List, Linux API, linux-efi
On Tue, Apr 3, 2018 at 12:01 PM, Andy Lutomirski <luto@kernel.org> wrote:
> On Tue, Apr 3, 2018 at 11:45 AM, Kees Cook <keescook@chromium.org> wrote:
>> On Tue, Apr 3, 2018 at 9:45 AM, Andy Lutomirski <luto@kernel.org> wrote:
>>> On Tue, Apr 3, 2018 at 9:29 AM, Matthew Garrett <mjg59@google.com> wrote:
>>>> On Tue, Apr 3, 2018 at 8:11 AM Andy Lutomirski <luto@kernel.org> wrote:
>>>>> Can you explain that much more clearly? I'm asking why booting via
>>>>> UEFI Secure Boot should enable lockdown, and I don't see what this has
>>>>> to do with kexec. And "someone blacklist[ing] your key in the
>>>>> bootloader" sounds like a political issue, not a technical issue.
>>>>
>>>> A kernel that allows users arbitrary access to ring 0 is just an
>>>> overfeatured bootloader. Why would you want secure boot in that case?
>>>
>>> To get a chain of trust. I can provision a system with some public
>>> keys, stored in UEFI authenticated variables, such that the system
>>> will only boot a signed image. That signed image, can, in turn, load
>>> a signed (or hashed or otherwise verfified) kernel and a verified
>>> initramfs. The initramfs can run a full system from a verified (using
>>> dm-verity or similar) filesystem, for example. Now it's very hard to
>>> persistently attack this system. Chromium OS does something very much
>>> like this, except that it doesn't use UEFI as far as I know. So does
>>> iOS, and so do some Android versions.
>>
>> Correct, Chrome OS does not use UEFI, and we still want this patch
>> series, as it plugs all the known "intentional" escalation paths from
>> uid-0 to ring-0. Happily, that means all the politics around the UEFI
>> and Secure Boot case can be ignored, because those issues are specific
>> to Secure Boot, not the lockdown series. (They are _related_, sure,
>> but lockdown isn't only about Secure Boot -- it's just that SB is one
>> of the widely deployed implementations of this kind of
>> trust-chain-booting-thing. Chrome OS and Android's Verified Boot do
>> similar things and have the same expectations about the uid-0/ring-0
>> separation.)
>>
>> The goal for that bright line on Chrome OS and Android is to stop
>> attack persistence. We want to know that a reboot onto a new kernel
>> and OS image will actually result in getting the desired system state,
>> and that any attack on persistent system data (even for things running
>> with full root privileges) can't result in using kernel interfaces to
>> gain kernel control. This isn't expected to be _perfect_, since
>> nothing is. But it creates a place to work from. The idea that uid-0
>> is NOT ring-0 is still relatively new, so the existing designs in the
>> kernel aren't well suited to building that distinction. I view this
>> series as a solid first step to getting there, though.
>
> But wouldn't Chrome OS possibly want to lock down kernel memory write
> vectors but not read vectors? After all, debugging is useful even on
> Chrome OS.
Chrome OS absolutely wants to block writing. We also want to block
reading as much as we possibly can, though yes we bump up against
debugging in that quest. But those cases are manageable and specific,
IMO.
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] x86/build changes for v4.17
@ 2018-04-05 0:20 92% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-04-05 0:20 UTC (permalink / raw)
To: Linus Torvalds
Cc: Matthias Kaehlcke, Arnd Bergmann, Peter Zijlstra, Ingo Molnar,
Linux Kernel Mailing List, Thomas Gleixner, Andrew Morton,
James Y Knight, Chandler Carruth, Stephen Hines,
Nick Desaulniers, Guenter Roeck, Greg Hackmann,
Greg Kroah-Hartman
On Wed, Apr 4, 2018 at 5:05 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Wed, Apr 4, 2018 at 4:31 PM, Matthias Kaehlcke <mka@chromium.org> wrote:
>>
>> From some experiments it looks like clang, in difference to gcc, does
>> not treat constant values passed as parameters to inline function as
>> constants.
>
> Yeah, I think gcc used to have those semantics a long time ago too.
>
> Many of our __builtin_constant_p() uses are indeed just in macros, but
> certainly not all.
>
> Other examples are found in our "fortified" string functions.
>
> There a clang build will likely simply miss some of the build-time
> fortification checks, and trigger them at runtime instead.
>
> Of course, we hopefully don't *have* any build-time failures, because
> gcc will have caught them, so you won't care as long as clang is a
> secondary compiler, but long-term they'd be good.
Yeah, it's used in inline functions in a lot of places. Some quickly
jump out: kmalloc, crypto, bitmaps, networking, uaccess, kvm, etc from
doing a dumb grep as:
git grep -B5 __builtin_constant_p | grep -A5 inline
FWIW, I prefer inline functions over macros just to keep type checking
a some level of sanity when reading build warnings/errors. ;)
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] USB/PHY driver patches for 4.17-rc1
@ 2018-04-05 6:31 92% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-04-05 6:31 UTC (permalink / raw)
To: Greg KH, Lars-Peter Clausen, Felipe Balbi, Al Viro
Cc: Linus Torvalds, Andrew Morton, LKML, linux-usb, Christoph Hellwig
On Wed, Apr 4, 2018 at 3:31 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> Lars-Peter Clausen (2):
> usb: gadget: ffs: Execute copy_to_user() with USER_DS set
https://git.kernel.org/linus/4058ebf33cb0be88ca516f968eda24ab7b6b93e4
Isn't there a better way to do this without the set_fs() usage? We've
been try to eliminate it in the kernel. I thought there was a safer
way to use iters now?
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] pstore updates for v4.17-rc1 (part 2)
@ 2018-04-08 17:20 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-04-08 17:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Arnd Bergmann, Tobias Regnery
Hi Linus,
Please pull this pstore fix for v4.17-rc1. This fixes another Kconfig
combination that Arnd and I missed for pstore's compression support.
Thanks!
-Kees
The following changes since commit 58eb5b6707477ff458db3ee522aac317da719e2a:
pstore: fix crypto dependencies (2018-03-15 10:06:06 -0700)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/pstore-v4.17-rc1-fix
for you to fetch changes up to e698aaf37f9fac419ac6c1867137cce83c90c80b:
pstore: fix crypto dependencies without compression (2018-04-06 15:45:33 -0700)
----------------------------------------------------------------
- Fix another compression Kconfig combination missed in testing (Tobias Regnery)
----------------------------------------------------------------
Tobias Regnery (1):
pstore: fix crypto dependencies without compression
fs/pstore/platform.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] rslib updates for v4.18-rc1
@ 2018-06-04 4:49 87% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-06-04 4:49 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Alasdair Kergon, Andrew Morton, Anton Vorontsov,
Boris Brezillon, Colin Cross, David Woodhouse, Mike Snitzer,
Neil Brown, Richard Weinberger, Segher Boessenkool,
Thomas Gleixner, Tony Luck
Hi Linus,
Please pull these rslib changes for v4.18-rc1. Thomas asked me to carry
this series since I've been coordinating VLA removal, and he's got enough
trees to worry about. :) This has been in -next for a while now.
Thanks!
-Kees
The following changes since commit 6d08b06e67cd117f6992c46611dfb4ce267cd71e:
Linux 4.17-rc2 (2018-04-22 19:20:09 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/rslib-v4.18-rc1
for you to fetch changes up to 45888b40d2a6221d46bb69959e2600ddba71cc1f:
rslib: Allocate decoder buffers to avoid VLAs (2018-04-24 19:50:10 -0700)
----------------------------------------------------------------
Refactors rslib and callers to provide a per-instance allocation area
instead of performing VLAs on the stack.
----------------------------------------------------------------
Thomas Gleixner (10):
rslib: Add GFP aware init function
dm/verity_fec: Use GFP aware reed solomon init
rslib: Cleanup whitespace damage
rslib: Cleanup top level comments
rslib: Add SPDX identifiers
rslib: Remove GPL boilerplate
rslib: Simplify error path
rslib: Split rs control struct
mtd: rawnand: diskonchip: Allocate rs control per instance
rslib: Allocate decoder buffers to avoid VLAs
drivers/md/dm-verity-fec.c | 2 +-
drivers/mtd/nand/raw/cafe_nand.c | 7 +-
drivers/mtd/nand/raw/diskonchip.c | 67 +++++------
include/linux/rslib.h | 74 +++++++-----
lib/reed_solomon/decode_rs.c | 34 +++---
lib/reed_solomon/encode_rs.c | 15 +--
lib/reed_solomon/reed_solomon.c | 240 ++++++++++++++++++++++----------------
7 files changed, 243 insertions(+), 196 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 87%]
* [GIT PULL] overflow changes for v4.18-rc1
@ 2018-06-06 18:40 63% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-06-06 18:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Rasmus Villemoes, Matthew Wilcox
Hi Linus,
Please pull these overflow changes for v4.18-rc1. As the tag notes, this
adds the new overflow checking helpers and adds them to the 2-factor
argument allocators. And this adds the saturating size helpers and does
a treewide replacement for the struct_size() usage. Additionally this
adds the overflow testing modules to make sure everything works.
I'm still working on the treewide replacements for allocators with "simple"
multiplied arguments (*alloc(a * b, ...) -> *alloc_array(a, b, ...) and
*zalloc(a * b, ...) -> *calloc(a, b, ...)) as well as the more complex
cases, but that's separable from this portion of the series. I expect to
have the rest sent before -rc1 closes; there are a lot of messy cases to
clean up.
Thanks!
-Kees
The following changes since commit 75bc37fefc4471e718ba8e651aa74673d4e0a9eb:
Linux 4.17-rc4 (2018-05-06 16:57:38 -1000)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/overflow-v4.18-rc1
for you to fetch changes up to 0ed2dd03b94b7b7f66e23f25073b5385d0416589:
treewide: Use struct_size() for devm_kmalloc() and friends (2018-06-06 11:15:43 -0700)
----------------------------------------------------------------
- Introduce arithmetic overflow test helper functions (Rasmus)
- Use overflow helpers in 2-factor allocators (Kees, Rasmus)
- Introduce overflow test module (Rasmus, Kees)
- Introduce saturating size helper functions (Matthew, Kees)
- Treewide use of struct_size() for allocators (Kees)
----------------------------------------------------------------
Kees Cook (9):
test_overflow: Report test failures
overflow.h: Add allocation size calculation helpers
test_overflow: Add memory allocation overflow tests
mm: Use overflow helpers in kmalloc_array*()
mm: Use overflow helpers in kvmalloc()
device: Use overflow helpers for devm_kmalloc()
treewide: Use struct_size() for kmalloc()-family
treewide: Use struct_size() for vmalloc()-family
treewide: Use struct_size() for devm_kmalloc() and friends
Rasmus Villemoes (3):
compiler.h: enable builtin overflow checkers and add fallback code
lib: add runtime test of check_*_overflow functions
test_overflow: macrofy some more, do more tests for free
crypto/af_alg.c | 4 +-
drivers/base/devres.c | 7 +-
drivers/clk/bcm/clk-bcm2835-aux.c | 6 +-
drivers/clk/bcm/clk-bcm2835.c | 4 +-
drivers/clk/bcm/clk-iproc-asiu.c | 4 +-
drivers/clk/bcm/clk-iproc-pll.c | 3 +-
drivers/clk/berlin/bg2.c | 3 +-
drivers/clk/berlin/bg2q.c | 3 +-
drivers/clk/clk-asm9260.c | 3 +-
drivers/clk/clk-aspeed.c | 6 +-
drivers/clk/clk-clps711x.c | 6 +-
drivers/clk/clk-efm32gg.c | 4 +-
drivers/clk/clk-gemini.c | 6 +-
drivers/clk/clk-s2mps11.c | 4 +-
drivers/clk/clk-scmi.c | 4 +-
drivers/clk/clk-stm32h7.c | 5 +-
drivers/clk/clk-stm32mp1.c | 5 +-
drivers/clk/davinci/da8xx-cfgchip.c | 4 +-
drivers/clk/mvebu/armada-37xx-periph.c | 7 +-
drivers/clk/mvebu/armada-37xx-tbg.c | 4 +-
drivers/clk/qcom/clk-spmi-pmic-div.c | 3 +-
drivers/clk/samsung/clk-exynos-audss.c | 4 +-
drivers/clk/samsung/clk-exynos-clkout.c | 3 +-
drivers/clk/samsung/clk-exynos5433.c | 4 +-
drivers/clk/samsung/clk-s3c2410-dclk.c | 7 +-
drivers/clk/samsung/clk-s5pv210-audss.c | 3 +-
drivers/dax/device.c | 2 +-
drivers/dma/bcm-sba-raid.c | 5 +-
drivers/dma/edma.c | 9 +-
drivers/dma/moxart-dma.c | 2 +-
drivers/dma/nbpfaxi.c | 4 +-
drivers/dma/omap-dma.c | 2 +-
drivers/dma/sa11x0-dma.c | 4 +-
drivers/dma/sh/usb-dmac.c | 2 +-
drivers/dma/sprd-dma.c | 4 +-
drivers/firewire/core-topology.c | 3 +-
drivers/gpio/gpio-uniphier.c | 3 +-
drivers/gpio/gpiolib.c | 3 +-
drivers/gpu/drm/nouveau/nvkm/core/ramht.c | 3 +-
drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c | 4 +-
drivers/hwspinlock/omap_hwspinlock.c | 2 +-
drivers/hwspinlock/sirf_hwspinlock.c | 6 +-
drivers/hwspinlock/u8500_hsem.c | 2 +-
drivers/infiniband/core/cache.c | 5 +-
drivers/infiniband/core/cm.c | 4 +-
drivers/infiniband/core/multicast.c | 2 +-
drivers/infiniband/core/uverbs_cmd.c | 4 +-
drivers/infiniband/core/uverbs_ioctl_merge.c | 21 +-
drivers/infiniband/hw/mthca/mthca_memfree.c | 4 +-
drivers/infiniband/sw/rdmavt/mr.c | 4 +-
drivers/input/input-leds.c | 3 +-
drivers/input/input-mt.c | 2 +-
drivers/input/keyboard/cap11xx.c | 3 +-
drivers/md/dm-raid.c | 2 +-
drivers/md/dm-table.c | 10 +-
drivers/mfd/qcom-pm8xxx.c | 4 +-
drivers/misc/cb710/core.c | 4 +-
drivers/misc/vexpress-syscfg.c | 3 +-
drivers/mtd/spi-nor/aspeed-smc.c | 5 +-
drivers/net/can/peak_canfd/peak_pciefd_main.c | 3 +-
drivers/net/ethernet/mellanox/mlx5/core/debugfs.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 3 +-
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 5 +-
drivers/net/wireless/mediatek/mt76/agg-rx.c | 3 +-
drivers/pinctrl/samsung/pinctrl-s3c64xx.c | 4 +-
drivers/pinctrl/uniphier/pinctrl-uniphier-core.c | 3 +-
drivers/regulator/mc13783-regulator.c | 6 +-
drivers/regulator/mc13892-regulator.c | 6 +-
drivers/reset/core.c | 3 +-
drivers/rtc/rtc-ac100.c | 8 +-
drivers/s390/cio/ccwgroup.c | 3 +-
drivers/soc/actions/owl-sps.c | 4 +-
drivers/soc/rockchip/pm_domains.c | 3 +-
drivers/staging/greybus/module.c | 4 +-
drivers/thermal/qcom/tsens.c | 6 +-
drivers/usb/gadget/function/f_midi.c | 5 +-
drivers/zorro/zorro.c | 3 +-
fs/afs/addr_list.c | 3 +-
include/linux/compiler-clang.h | 14 +
include/linux/compiler-gcc.h | 4 +
include/linux/compiler-intel.h | 4 +
include/linux/device.h | 8 +-
include/linux/mm.h | 7 +-
include/linux/overflow.h | 278 +++++++++++++++
include/linux/slab.h | 17 +-
include/linux/vmalloc.h | 1 +
kernel/cgroup/cgroup.c | 4 +-
kernel/module.c | 3 +-
kernel/workqueue.c | 3 +-
lib/Kconfig.debug | 3 +
lib/Makefile | 1 +
lib/test_overflow.c | 417 ++++++++++++++++++++++
net/ceph/mon_client.c | 5 +-
net/ceph/osd_client.c | 3 +-
net/netfilter/xt_recent.c | 3 +-
net/sctp/endpointola.c | 4 +-
sound/core/vmaster.c | 4 +-
sound/soc/qcom/apq8016_sbc.c | 3 +-
sound/soc/soc-dapm.c | 2 +-
99 files changed, 916 insertions(+), 205 deletions(-)
create mode 100644 include/linux/overflow.h
create mode 100644 lib/test_overflow.c
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 63%]
* [GIT PULL] overflow updates (part 2) for v4.18-rc1
@ 2018-06-12 23:35 16% Kees Cook
0 siblings, 1 reply; 200+ results
From: Kees Cook @ 2018-06-12 23:35 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Dan Carpenter, Silvio Cesare, Kees Cook, Matthew Wilcox
Hi Linus,
Please pull the rest of the overflow changes for v4.18-rc1. This includes
the explicit overflow fixes from Silvio, further struct_size() conversions
from Matthew, a bug fix from Dan, but the bulk are the treewide conversions
to use either the 2-factor argument allocators (e.g. kmalloc(a * b, ...)
into kmalloc_array(a, b, ...) or the array_size() macros (e.g. vmalloc(a * b)
into vmalloc(array_size(a, b)). Coccinelle was fighting me on several fronts,
so I've done a bunch of manual whitespace updates in the patches as well.
Thanks!
-Kees
The following changes since commit d54d35c501bcbd57b9722a6b371c0608b5d34199:
Merge tag 'f2fs-for-4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs (2018-06-11 10:16:13 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/overflow-v4.18-rc1-part2
for you to fetch changes up to 9d2a789c1db75d0f55b14fa57bec548d94332ad8:
treewide: Use array_size in f2fs_kvzalloc() (2018-06-12 16:19:22 -0700)
----------------------------------------------------------------
- Error path bug fix for overflow tests (Dan)
- Additional struct_size() conversions (Matthew, Kees)
- Explicitly reported overflow fixes (Silvio, Kees)
- Add missing kvcalloc() function (Kees)
- Treewide conversions of allocators to use either 2-factor argument
variant when available, or array_size() and array3_size() as needed (Kees)
----------------------------------------------------------------
Dan Carpenter (1):
test_overflow: fix an IS_ERR() vs NULL bug
Kees Cook (18):
leds: Use struct_size() in allocation
video: uvesafb: Fix integer overflow in allocation
mm: Introduce kvcalloc()
treewide: kmalloc() -> kmalloc_array()
treewide: kzalloc() -> kcalloc()
treewide: kzalloc_node() -> kcalloc_node()
treewide: kvmalloc() -> kvmalloc_array()
treewide: kvzalloc() -> kvcalloc()
treewide: devm_kmalloc() -> devm_kmalloc_array()
treewide: devm_kzalloc() -> devm_kcalloc()
treewide: Use array_size() in vmalloc()
treewide: Use array_size() in vzalloc()
treewide: Use array_size() in vzalloc_node()
treewide: Use array_size() in kvzalloc_node()
treewide: Use array_size() in sock_kmalloc()
treewide: Use array_size() in f2fs_kmalloc()
treewide: Use array_size() in f2fs_kzalloc()
treewide: Use array_size in f2fs_kvzalloc()
Matthew Wilcox (6):
Convert virtio_console to struct_size
Convert infiniband uverbs to struct_size
Convert v4l2 event to struct_size
Convert vhost to struct_size
Convert jffs2 acl to struct_size
Convert intel uncore to struct_size
Silvio Cesare (1):
UBIFS: Fix potential integer overflow in allocation
arch/arm/kernel/sys_oabi-compat.c | 4 +-
arch/arm/mach-footbridge/dc21285.c | 2 +-
arch/arm/mach-ixp4xx/common-pci.c | 2 +-
arch/arm/mach-omap1/mcbsp.c | 2 +-
arch/arm/mach-omap2/hsmmc.c | 2 +-
arch/arm/mach-omap2/omap_device.c | 4 +-
arch/arm/mach-omap2/prm_common.c | 9 ++--
arch/arm/mach-vexpress/spc.c | 2 +-
arch/arm/mm/dma-mapping.c | 4 +-
arch/arm/mm/pgd.c | 2 +-
arch/arm/probes/kprobes/test-core.c | 5 +-
arch/arm64/kernel/armv8_deprecated.c | 4 +-
arch/arm64/mm/context.c | 2 +-
arch/ia64/kernel/mca_drv.c | 3 +-
arch/ia64/kernel/topology.c | 6 +--
arch/ia64/mm/tlb.c | 5 +-
arch/ia64/sn/kernel/io_common.c | 2 +-
arch/ia64/sn/kernel/irq.c | 3 +-
arch/ia64/sn/pci/pcibr/pcibr_provider.c | 2 +-
arch/mips/alchemy/common/clock.c | 2 +-
arch/mips/alchemy/common/dbdma.c | 6 +--
arch/mips/alchemy/common/platform.c | 4 +-
arch/mips/alchemy/devboards/platform.c | 4 +-
arch/mips/bmips/dma.c | 2 +-
arch/mips/txx9/rbtx4939/setup.c | 2 +-
arch/powerpc/kernel/rtasd.c | 3 +-
arch/powerpc/kernel/vdso.c | 4 +-
arch/powerpc/kvm/book3s_64_mmu_hv.c | 2 +-
arch/powerpc/kvm/book3s_hv.c | 2 +-
arch/powerpc/lib/rheap.c | 2 +-
arch/powerpc/mm/mmu_context_iommu.c | 2 +-
arch/powerpc/mm/numa.c | 2 +-
arch/powerpc/net/bpf_jit_comp.c | 2 +-
arch/powerpc/net/bpf_jit_comp64.c | 2 +-
arch/powerpc/oprofile/cell/spu_profiler.c | 4 +-
arch/powerpc/platforms/4xx/hsta_msi.c | 3 +-
arch/powerpc/platforms/4xx/msi.c | 2 +-
arch/powerpc/platforms/4xx/pci.c | 2 +-
arch/powerpc/platforms/powernv/opal-sysparam.c | 8 ++--
arch/powerpc/sysdev/mpic.c | 9 ++--
arch/powerpc/sysdev/xive/native.c | 2 +-
arch/s390/appldata/appldata_base.c | 2 +-
arch/s390/hypfs/hypfs_diag.c | 2 +-
arch/s390/hypfs/hypfs_diag0c.c | 3 +-
arch/s390/kernel/debug.c | 6 ++-
arch/s390/kernel/module.c | 4 +-
arch/s390/kernel/perf_cpum_cf_events.c | 2 +-
arch/s390/kernel/sthyi.c | 2 +-
arch/s390/kernel/vdso.c | 4 +-
arch/s390/kvm/gaccess.c | 2 +-
arch/s390/kvm/kvm-s390.c | 2 +-
arch/s390/mm/extmem.c | 2 +-
arch/sh/drivers/dma/dmabrg.c | 2 +-
arch/sh/drivers/pci/pcie-sh7786.c | 2 +-
arch/sparc/kernel/nmi.c | 3 +-
arch/sparc/kernel/sys_sparc_64.c | 8 ++--
arch/sparc/net/bpf_jit_comp_32.c | 2 +-
arch/um/drivers/ubd_kern.c | 12 ++---
arch/um/drivers/vector_kern.c | 12 ++---
arch/unicore32/kernel/pm.c | 5 +-
arch/x86/events/amd/iommu.c | 2 +-
arch/x86/events/core.c | 2 +-
arch/x86/events/intel/uncore.c | 21 +++++----
arch/x86/kernel/cpu/mcheck/mce.c | 2 +-
arch/x86/kernel/cpu/mcheck/mce_amd.c | 2 +-
arch/x86/kernel/cpu/mtrr/if.c | 2 +-
arch/x86/kernel/hpet.c | 6 +--
arch/x86/kernel/ksysfs.c | 2 +-
arch/x86/kvm/cpuid.c | 8 ++--
arch/x86/kvm/page_track.c | 5 +-
arch/x86/kvm/svm.c | 4 +-
arch/x86/kvm/x86.c | 5 +-
arch/x86/net/bpf_jit_comp.c | 2 +-
arch/x86/net/bpf_jit_comp32.c | 2 +-
arch/x86/pci/xen.c | 2 +-
arch/x86/platform/uv/tlb_uv.c | 2 +-
arch/x86/platform/uv/uv_time.c | 2 +-
block/bio.c | 3 +-
block/blk-mq.c | 16 +++----
block/blk-tag.c | 4 +-
block/blk-zoned.c | 4 +-
block/partitions/check.c | 2 +-
block/partitions/ldm.c | 2 +-
crypto/algif_aead.c | 4 +-
crypto/algif_skcipher.c | 3 +-
crypto/testmgr.c | 3 +-
drivers/acpi/acpi_platform.c | 2 +-
drivers/acpi/acpi_video.c | 5 +-
drivers/acpi/apei/erst.c | 3 +-
drivers/acpi/apei/hest.c | 3 +-
drivers/acpi/fan.c | 4 +-
drivers/acpi/nfit/core.c | 7 +--
drivers/acpi/processor_perflib.c | 5 +-
drivers/acpi/processor_throttling.c | 5 +-
drivers/acpi/sysfs.c | 6 +--
drivers/android/binder_alloc.c | 4 +-
drivers/ata/libata-core.c | 2 +-
drivers/ata/libata-pmp.c | 2 +-
drivers/ata/sata_mv.c | 8 ++--
drivers/atm/fore200e.c | 3 +-
drivers/atm/iphase.c | 2 +-
drivers/atm/solos-pci.c | 3 +-
drivers/auxdisplay/cfag12864b.c | 4 +-
drivers/base/firmware_loader/fallback.c | 2 +-
drivers/block/DAC960.c | 4 +-
drivers/block/drbd/drbd_main.c | 3 +-
drivers/block/loop.c | 3 +-
drivers/block/null_blk.c | 9 ++--
drivers/block/ps3vram.c | 5 +-
drivers/block/rsxx/core.c | 3 +-
drivers/block/rsxx/dma.c | 2 +-
drivers/block/xen-blkback/xenbus.c | 3 +-
drivers/block/xen-blkfront.c | 23 +++++----
drivers/block/z2ram.c | 5 +-
drivers/block/zram/zram_drv.c | 2 +-
drivers/bus/fsl-mc/fsl-mc-allocator.c | 6 +--
drivers/cdrom/cdrom.c | 2 +-
drivers/char/agp/amd-k7-agp.c | 3 +-
drivers/char/agp/ati-agp.c | 3 +-
drivers/char/agp/compat_ioctl.c | 8 +++-
drivers/char/agp/isoch.c | 3 +-
drivers/char/agp/sgi-agp.c | 6 +--
drivers/char/agp/sworks-agp.c | 2 +-
drivers/char/agp/uninorth-agp.c | 4 +-
drivers/char/ipmi/ipmi_ssif.c | 3 +-
drivers/char/raw.c | 3 +-
drivers/char/tpm/tpm2-cmd.c | 2 +-
drivers/char/virtio_console.c | 18 ++++----
drivers/clk/bcm/clk-bcm2835.c | 4 +-
drivers/clk/renesas/clk-r8a7740.c | 2 +-
drivers/clk/renesas/clk-r8a7779.c | 2 +-
drivers/clk/renesas/clk-rcar-gen2.c | 2 +-
drivers/clk/renesas/clk-rz.c | 2 +-
drivers/clk/st/clkgen-fsyn.c | 2 +-
drivers/clk/st/clkgen-pll.c | 2 +-
drivers/clk/sunxi/clk-usb.c | 2 +-
drivers/clk/tegra/clk.c | 7 +--
drivers/clk/ti/adpll.c | 6 ++-
drivers/clk/ti/apll.c | 2 +-
drivers/clk/ti/divider.c | 4 +-
drivers/clk/ti/dpll.c | 2 +-
drivers/clocksource/sh_cmt.c | 2 +-
drivers/clocksource/sh_mtu2.c | 2 +-
drivers/clocksource/sh_tmu.c | 2 +-
drivers/cpufreq/acpi-cpufreq.c | 4 +-
drivers/cpufreq/arm_big_little.c | 2 +-
drivers/cpufreq/bmips-cpufreq.c | 2 +-
drivers/cpufreq/brcmstb-avs-cpufreq.c | 2 +-
drivers/cpufreq/cppc_cpufreq.c | 3 +-
drivers/cpufreq/ia64-acpi-cpufreq.c | 4 +-
drivers/cpufreq/imx6q-cpufreq.c | 3 +-
drivers/cpufreq/intel_pstate.c | 2 +-
drivers/cpufreq/longhaul.c | 4 +-
drivers/cpufreq/pxa3xx-cpufreq.c | 2 +-
drivers/cpufreq/s3c24xx-cpufreq.c | 2 +-
drivers/cpufreq/sfi-cpufreq.c | 4 +-
drivers/cpufreq/spear-cpufreq.c | 2 +-
drivers/crypto/amcc/crypto4xx_core.c | 8 ++--
drivers/crypto/cavium/nitrox/nitrox_isr.c | 2 +-
drivers/crypto/chelsio/chtls/chtls_io.c | 2 +-
drivers/crypto/inside-secure/safexcel_hash.c | 2 +-
drivers/crypto/marvell/cesa.c | 2 +-
drivers/crypto/marvell/hash.c | 2 +-
drivers/crypto/n2_core.c | 4 +-
drivers/crypto/qat/qat_common/adf_isr.c | 2 +-
drivers/crypto/qat/qat_common/qat_uclo.c | 5 +-
drivers/crypto/stm32/stm32-hash.c | 5 +-
drivers/crypto/talitos.c | 13 ++++--
drivers/crypto/virtio/virtio_crypto_algs.c | 2 +-
drivers/devfreq/devfreq.c | 15 +++---
drivers/devfreq/event/exynos-ppmu.c | 2 +-
drivers/dma/bestcomm/bestcomm.c | 3 +-
drivers/dma/ioat/init.c | 4 +-
drivers/dma/ipu/ipu_idmac.c | 3 +-
drivers/dma/k3dma.c | 8 ++--
drivers/dma/mic_x100_dma.c | 3 +-
drivers/dma/mv_xor.c | 4 +-
drivers/dma/mv_xor_v2.c | 5 +-
drivers/dma/pl330.c | 4 +-
drivers/dma/s3c24xx-dma.c | 6 +--
drivers/dma/sh/shdma-base.c | 5 +-
drivers/dma/xilinx/zynqmp_dma.c | 2 +-
drivers/dma/zx_dma.c | 8 ++--
drivers/edac/amd64_edac.c | 2 +-
drivers/edac/i7core_edac.c | 2 +-
drivers/extcon/extcon.c | 24 ++++++----
drivers/firewire/core-iso.c | 4 +-
drivers/firewire/net.c | 2 +-
drivers/firmware/arm_scpi.c | 2 +-
drivers/firmware/dell_rbu.c | 2 +-
drivers/firmware/efi/capsule.c | 2 +-
drivers/firmware/efi/runtime-map.c | 2 +-
drivers/firmware/ti_sci.c | 6 +--
drivers/fmc/fmc-sdb.c | 4 +-
drivers/gpio/gpio-adnp.c | 2 +-
drivers/gpio/gpio-aspeed.c | 4 +-
drivers/gpio/gpio-bcm-kona.c | 7 +--
drivers/gpio/gpio-davinci.c | 4 +-
drivers/gpio/gpio-htc-egpio.c | 4 +-
drivers/gpio/gpio-ml-ioh.c | 2 +-
drivers/gpio/gpio-thunderx.c | 9 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c | 6 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_test.c | 2 +-
drivers/gpu/drm/amd/amdgpu/atom.c | 2 +-
drivers/gpu/drm/amd/amdgpu/ci_dpm.c | 9 ++--
drivers/gpu/drm/amd/amdgpu/kv_dpm.c | 5 +-
drivers/gpu/drm/amd/amdgpu/si_dpm.c | 9 ++--
.../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
drivers/gpu/drm/amd/display/dc/basics/logger.c | 2 +-
drivers/gpu/drm/amd/display/dc/basics/vector.c | 4 +-
.../gpu/drm/amd/display/dc/dce/dce_clock_source.c | 6 ++-
drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c | 3 +-
.../drm/amd/display/modules/color/color_gamma.c | 47 +++++++++++--------
.../drm/amd/display/modules/freesync/freesync.c | 3 +-
drivers/gpu/drm/amd/display/modules/stats/stats.c | 12 ++---
drivers/gpu/drm/amd/powerplay/hwmgr/pp_psm.c | 2 +-
drivers/gpu/drm/drm_edid.c | 3 +-
drivers/gpu/drm/drm_hashtab.c | 2 +-
drivers/gpu/drm/drm_memory.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 4 +-
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 3 +-
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 5 +-
drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +-
drivers/gpu/drm/gma500/mid_bios.c | 2 +-
drivers/gpu/drm/i915/gvt/gtt.c | 5 +-
drivers/gpu/drm/i915/gvt/mmio.c | 2 +-
drivers/gpu/drm/i915/gvt/vgpu.c | 2 +-
drivers/gpu/drm/i915/intel_hdcp.c | 2 +-
drivers/gpu/drm/i915/selftests/intel_uncore.c | 2 +-
drivers/gpu/drm/msm/hdmi/hdmi.c | 24 ++++++----
drivers/gpu/drm/msm/hdmi/hdmi_phy.c | 4 +-
drivers/gpu/drm/nouveau/nv84_fence.c | 2 +-
drivers/gpu/drm/nouveau/nvif/fifo.c | 4 +-
drivers/gpu/drm/nouveau/nvif/mmu.c | 9 ++--
drivers/gpu/drm/nouveau/nvif/object.c | 2 +-
drivers/gpu/drm/nouveau/nvif/vmm.c | 3 +-
drivers/gpu/drm/nouveau/nvkm/core/event.c | 3 +-
drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c | 2 +-
.../gpu/drm/nouveau/nvkm/subdev/bios/iccsense.c | 3 +-
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c | 2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/mem.c | 4 +-
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 2 +-
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 4 +-
drivers/gpu/drm/omapdrm/omap_gem.c | 4 +-
drivers/gpu/drm/qxl/qxl_fb.c | 2 +-
drivers/gpu/drm/qxl/qxl_kms.c | 4 +-
drivers/gpu/drm/radeon/atom.c | 2 +-
drivers/gpu/drm/radeon/btc_dpm.c | 4 +-
drivers/gpu/drm/radeon/ci_dpm.c | 9 ++--
drivers/gpu/drm/radeon/kv_dpm.c | 5 +-
drivers/gpu/drm/radeon/ni_dpm.c | 9 ++--
drivers/gpu/drm/radeon/r600_dpm.c | 2 +-
drivers/gpu/drm/radeon/radeon_atombios.c | 39 ++++++++++------
drivers/gpu/drm/radeon/radeon_combios.c | 9 ++--
drivers/gpu/drm/radeon/radeon_gart.c | 7 +--
drivers/gpu/drm/radeon/radeon_test.c | 2 +-
drivers/gpu/drm/radeon/rs780_dpm.c | 5 +-
drivers/gpu/drm/radeon/rv6xx_dpm.c | 5 +-
drivers/gpu/drm/radeon/rv770_dpm.c | 5 +-
drivers/gpu/drm/radeon/si_dpm.c | 9 ++--
drivers/gpu/drm/radeon/sumo_dpm.c | 5 +-
drivers/gpu/drm/radeon/trinity_dpm.c | 5 +-
drivers/gpu/drm/savage/savage_bci.c | 5 +-
drivers/gpu/drm/selftests/test-drm_mm.c | 24 +++++-----
drivers/gpu/drm/tinydrm/repaper.c | 2 +-
drivers/gpu/drm/ttm/ttm_page_alloc.c | 8 ++--
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 8 ++--
drivers/gpu/drm/vc4/vc4_plane.c | 2 +-
drivers/gpu/drm/via/via_dmablit.c | 2 +-
drivers/hid/hid-core.c | 9 ++--
drivers/hid/hid-debug.c | 6 +--
drivers/hid/hid-picolcd_fb.c | 3 +-
drivers/hid/hid-sensor-hub.c | 3 +-
drivers/hid/hidraw.c | 2 +-
drivers/hid/intel-ish-hid/ishtp-hid-client.c | 4 +-
drivers/hid/wacom_sys.c | 4 +-
drivers/hv/hv.c | 2 +-
drivers/hv/ring_buffer.c | 2 +-
drivers/hwmon/acpi_power_meter.c | 7 +--
drivers/hwmon/aspeed-pwm-tacho.c | 2 +-
drivers/hwmon/coretemp.c | 2 +-
drivers/hwmon/gpio-fan.c | 8 ++--
drivers/hwmon/i5k_amb.c | 5 +-
drivers/hwmon/ibmpex.c | 2 +-
drivers/hwmon/ibmpowernv.c | 9 ++--
drivers/hwmon/iio_hwmon.c | 4 +-
drivers/hwmon/nct6683.c | 4 +-
drivers/hwmon/nct6775.c | 4 +-
drivers/hwmon/pmbus/pmbus_core.c | 4 +-
drivers/hwmon/pmbus/ucd9000.c | 4 +-
drivers/hwmon/pwm-fan.c | 2 +-
drivers/hwtracing/coresight/coresight-etb10.c | 4 +-
drivers/hwtracing/coresight/of_coresight.c | 9 ++--
drivers/i2c/busses/i2c-amd756-s4882.c | 4 +-
drivers/i2c/busses/i2c-nforce2-s4985.c | 4 +-
drivers/i2c/busses/i2c-nforce2.c | 2 +-
drivers/i2c/busses/i2c-qup.c | 8 ++--
drivers/i2c/i2c-dev.c | 2 +-
drivers/i2c/i2c-stub.c | 5 +-
drivers/i2c/muxes/i2c-mux-gpio.c | 9 ++--
drivers/i2c/muxes/i2c-mux-reg.c | 4 +-
drivers/ide/hpt366.c | 2 +-
drivers/ide/ide-probe.c | 5 +-
drivers/ide/it821x.c | 2 +-
drivers/iio/adc/at91_adc.c | 7 +--
drivers/iio/adc/max1027.c | 4 +-
drivers/iio/adc/max1363.c | 6 ++-
drivers/iio/adc/twl6030-gpadc.c | 7 +--
drivers/iio/dac/ad5592r-base.c | 5 +-
drivers/iio/imu/adis_buffer.c | 2 +-
drivers/iio/inkern.c | 2 +-
drivers/iio/multiplexer/iio-mux.c | 7 +--
drivers/infiniband/core/cache.c | 5 +-
drivers/infiniband/core/cma.c | 4 +-
drivers/infiniband/core/device.c | 4 +-
drivers/infiniband/core/fmr_pool.c | 5 +-
drivers/infiniband/core/iwpm_util.c | 10 ++--
drivers/infiniband/core/umem_odp.c | 16 ++++---
drivers/infiniband/core/uverbs_cmd.c | 4 +-
drivers/infiniband/hw/cxgb3/cxio_hal.c | 4 +-
drivers/infiniband/hw/cxgb4/device.c | 7 +--
drivers/infiniband/hw/cxgb4/id_table.c | 4 +-
drivers/infiniband/hw/cxgb4/qp.c | 8 ++--
drivers/infiniband/hw/hfi1/sdma.c | 3 +-
drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 2 +-
drivers/infiniband/hw/hns/hns_roce_mr.c | 2 +-
drivers/infiniband/hw/mlx4/mad.c | 3 +-
drivers/infiniband/hw/mlx4/main.c | 12 +++--
drivers/infiniband/hw/mlx4/qp.c | 4 +-
drivers/infiniband/hw/mlx5/srq.c | 4 +-
drivers/infiniband/hw/mthca/mthca_allocator.c | 18 +++++---
drivers/infiniband/hw/mthca/mthca_cmd.c | 6 +--
drivers/infiniband/hw/mthca/mthca_eq.c | 6 +--
drivers/infiniband/hw/mthca/mthca_memfree.c | 6 +--
drivers/infiniband/hw/mthca/mthca_mr.c | 4 +-
drivers/infiniband/hw/mthca/mthca_profile.c | 2 +-
drivers/infiniband/hw/mthca/mthca_qp.c | 4 +-
drivers/infiniband/hw/mthca/mthca_srq.c | 2 +-
drivers/infiniband/hw/nes/nes_mgt.c | 3 +-
drivers/infiniband/hw/nes/nes_nic.c | 2 +-
drivers/infiniband/hw/nes/nes_verbs.c | 5 +-
drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 2 +-
drivers/infiniband/hw/ocrdma/ocrdma_main.c | 11 +++--
drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 15 +++---
drivers/infiniband/hw/qedr/main.c | 4 +-
drivers/infiniband/hw/qedr/verbs.c | 4 +-
drivers/infiniband/hw/qib/qib_iba6120.c | 9 ++--
drivers/infiniband/hw/qib/qib_iba7220.c | 9 ++--
drivers/infiniband/hw/qib/qib_iba7322.c | 34 ++++++++------
drivers/infiniband/hw/qib/qib_init.c | 14 +++---
drivers/infiniband/hw/usnic/usnic_ib_qp_grp.c | 2 +-
drivers/infiniband/hw/usnic/usnic_vnic.c | 2 +-
drivers/infiniband/sw/rdmavt/qp.c | 11 ++---
drivers/infiniband/ulp/ipoib/ipoib_cm.c | 8 ++--
drivers/infiniband/ulp/ipoib/ipoib_main.c | 10 ++--
drivers/infiniband/ulp/iser/iser_initiator.c | 5 +-
drivers/infiniband/ulp/isert/ib_isert.c | 5 +-
drivers/infiniband/ulp/srp/ib_srp.c | 9 ++--
drivers/infiniband/ulp/srpt/ib_srpt.c | 2 +-
drivers/input/joystick/joydump.c | 2 +-
drivers/input/keyboard/clps711x-keypad.c | 4 +-
drivers/input/keyboard/matrix_keypad.c | 6 +--
drivers/input/keyboard/omap4-keypad.c | 3 +-
drivers/input/keyboard/samsung-keypad.c | 2 +-
drivers/input/matrix-keymap.c | 4 +-
drivers/input/misc/rotary_encoder.c | 4 +-
drivers/input/rmi4/rmi_driver.c | 9 ++--
drivers/input/rmi4/rmi_f11.c | 15 +++---
drivers/input/rmi4/rmi_f12.c | 15 +++---
drivers/input/rmi4/rmi_f54.c | 2 +-
drivers/input/rmi4/rmi_spi.c | 9 ++--
drivers/iommu/arm-smmu.c | 2 +-
drivers/iommu/dmar.c | 2 +-
drivers/iommu/intel-iommu.c | 4 +-
drivers/iommu/omap-iommu.c | 2 +-
drivers/iommu/rockchip-iommu.c | 2 +-
drivers/iommu/tegra-gart.c | 2 +-
drivers/ipack/carriers/tpci200.c | 4 +-
drivers/irqchip/irq-alpine-msi.c | 3 +-
drivers/irqchip/irq-gic-v2m.c | 2 +-
drivers/irqchip/irq-gic-v3-its.c | 19 ++++----
drivers/irqchip/irq-gic-v3.c | 5 +-
drivers/irqchip/irq-imgpdc.c | 2 +-
drivers/irqchip/irq-mvebu-gicp.c | 8 ++--
drivers/irqchip/irq-partition-percpu.c | 2 +-
drivers/irqchip/irq-s3c24xx.c | 2 +-
drivers/isdn/capi/capi.c | 2 +-
drivers/isdn/capi/capidrv.c | 3 +-
drivers/isdn/gigaset/capi.c | 6 +--
drivers/isdn/gigaset/common.c | 4 +-
drivers/isdn/gigaset/i4l.c | 2 +-
drivers/isdn/hardware/avm/b1.c | 2 +-
drivers/isdn/hisax/fsm.c | 4 +-
drivers/isdn/hisax/hfc_2bds0.c | 2 +-
drivers/isdn/hisax/hfc_2bs0.c | 3 +-
drivers/isdn/hisax/netjet.c | 12 +++--
drivers/isdn/i4l/isdn_bsdcomp.c | 5 +-
drivers/isdn/i4l/isdn_common.c | 10 ++--
drivers/isdn/mISDN/fsm.c | 6 ++-
drivers/leds/leds-adp5520.c | 2 +-
drivers/leds/leds-apu.c | 4 +-
drivers/leds/leds-cr0014114.c | 3 +-
drivers/leds/leds-da9052.c | 4 +-
drivers/leds/leds-lp5521.c | 4 +-
drivers/leds/leds-lp5523.c | 4 +-
drivers/leds/leds-lp5562.c | 4 +-
drivers/leds/leds-lp55xx-common.c | 2 +-
drivers/leds/leds-lp8501.c | 4 +-
drivers/leds/leds-lt3593.c | 4 +-
drivers/leds/leds-mc13783.c | 4 +-
drivers/leds/leds-mlxcpld.c | 6 ++-
drivers/leds/leds-netxbig.c | 16 +++----
drivers/leds/leds-ns2.c | 7 +--
drivers/leds/leds-pca955x.c | 8 ++--
drivers/leds/leds-pca963x.c | 6 +--
drivers/leds/leds-tca6507.c | 4 +-
drivers/lightnvm/pblk-gc.c | 2 +-
drivers/lightnvm/pblk-init.c | 8 ++--
drivers/lightnvm/pblk-recovery.c | 2 +-
drivers/mailbox/hi6220-mailbox.c | 8 ++--
drivers/mailbox/mailbox-sti.c | 4 +-
drivers/mailbox/omap-mailbox.c | 10 ++--
drivers/mailbox/pcc.c | 3 +-
drivers/mailbox/ti-msgmgr.c | 4 +-
drivers/md/bcache/super.c | 11 +++--
drivers/md/bcache/sysfs.c | 3 +-
drivers/md/dm-cache-policy-smq.c | 4 +-
drivers/md/dm-crypt.c | 5 +-
drivers/md/dm-integrity.c | 18 ++++++--
drivers/md/dm-region-hash.c | 2 +-
drivers/md/dm-snap.c | 9 ++--
drivers/md/dm-stats.c | 4 +-
drivers/md/dm-switch.c | 3 +-
drivers/md/dm-table.c | 2 +-
drivers/md/dm-thin.c | 4 +-
drivers/md/dm-verity-target.c | 5 +-
drivers/md/md-bitmap.c | 6 +--
drivers/md/md-cluster.c | 6 +--
drivers/md/md-multipath.c | 3 +-
drivers/md/raid0.c | 10 ++--
drivers/md/raid1.c | 13 +++---
drivers/md/raid10.c | 15 +++---
drivers/md/raid5.c | 15 +++---
drivers/media/common/v4l2-tpg/v4l2-tpg-core.c | 15 ++++--
drivers/media/dvb-core/dmxdev.c | 3 +-
drivers/media/dvb-core/dvb_demux.c | 6 ++-
drivers/media/dvb-frontends/dib7000p.c | 4 +-
drivers/media/dvb-frontends/dib8000.c | 4 +-
drivers/media/dvb-frontends/dib9000.c | 4 +-
drivers/media/i2c/s5k5baf.c | 2 +-
drivers/media/pci/bt8xx/bttv-risc.c | 3 +-
drivers/media/pci/cx23885/cx23885-alsa.c | 2 +-
drivers/media/pci/cx25821/cx25821-alsa.c | 2 +-
drivers/media/pci/cx88/cx88-alsa.c | 2 +-
drivers/media/pci/ivtv/ivtvfb.c | 2 +-
drivers/media/pci/meye/meye.c | 2 +-
drivers/media/pci/pt1/pt1.c | 2 +-
drivers/media/pci/saa7134/saa7134-alsa.c | 2 +-
drivers/media/pci/ttpci/av7110_ipack.c | 2 +-
drivers/media/platform/am437x/am437x-vpfe.c | 6 ++-
drivers/media/platform/davinci/vpif_capture.c | 10 ++--
.../media/platform/qcom/camss-8x16/camss-csid.c | 8 ++--
.../media/platform/qcom/camss-8x16/camss-csiphy.c | 11 +++--
.../media/platform/qcom/camss-8x16/camss-ispif.c | 9 ++--
drivers/media/platform/qcom/camss-8x16/camss-vfe.c | 8 ++--
drivers/media/platform/qcom/camss-8x16/camss.c | 3 +-
drivers/media/platform/soc_camera/soc_camera.c | 3 +-
drivers/media/platform/vivid/vivid-core.c | 9 ++--
drivers/media/platform/vsp1/vsp1_entity.c | 3 +-
drivers/media/platform/xilinx/xilinx-vipp.c | 2 +-
drivers/media/usb/au0828/au0828-video.c | 6 +--
drivers/media/usb/cpia2/cpia2_usb.c | 3 +-
drivers/media/usb/cx231xx/cx231xx-audio.c | 2 +-
drivers/media/usb/cx231xx/cx231xx-core.c | 8 ++--
drivers/media/usb/cx231xx/cx231xx-vbi.c | 4 +-
drivers/media/usb/go7007/go7007-fw.c | 2 +-
drivers/media/usb/go7007/go7007-usb.c | 3 +-
drivers/media/usb/gspca/t613.c | 2 +-
drivers/media/usb/pvrusb2/pvrusb2-hdw.c | 2 +-
drivers/media/usb/pvrusb2/pvrusb2-std.c | 2 +-
drivers/media/usb/stk1160/stk1160-core.c | 5 +-
drivers/media/usb/stk1160/stk1160-video.c | 6 +--
drivers/media/usb/stkwebcam/stk-webcam.c | 5 +-
drivers/media/usb/tm6000/tm6000-video.c | 13 ++++--
drivers/media/usb/usbtv/usbtv-video.c | 2 +-
drivers/media/usb/usbvision/usbvision-video.c | 3 +-
drivers/media/usb/uvc/uvc_video.c | 4 +-
drivers/media/v4l2-core/v4l2-event.c | 3 +-
drivers/media/v4l2-core/v4l2-flash-led-class.c | 7 +--
drivers/media/v4l2-core/videobuf-dma-sg.c | 7 +--
drivers/memory/of_memory.c | 4 +-
drivers/memstick/core/ms_block.c | 6 ++-
drivers/message/fusion/mptlan.c | 7 +--
drivers/mfd/ab8500-debugfs.c | 12 ++---
drivers/mfd/cros_ec_dev.c | 7 +--
drivers/mfd/htc-i2cpld.c | 4 +-
drivers/mfd/mfd-core.c | 2 +-
drivers/mfd/motorola-cpcap.c | 6 +--
drivers/mfd/sprd-sc27xx-spi.c | 5 +-
drivers/mfd/timberdale.c | 4 +-
drivers/mfd/twl-core.c | 5 +-
drivers/mfd/wm8994-core.c | 7 +--
drivers/misc/altera-stapl/altera.c | 6 +--
drivers/misc/cxl/guest.c | 2 +-
drivers/misc/cxl/of.c | 2 +-
drivers/misc/eeprom/idt_89hpesx.c | 2 +-
drivers/misc/genwqe/card_ddcb.c | 9 ++--
drivers/misc/sgi-xp/xpc_main.c | 8 ++--
drivers/misc/sgi-xp/xpc_partition.c | 2 +-
drivers/misc/sgi-xp/xpnet.c | 5 +-
drivers/misc/sram.c | 6 +--
drivers/misc/vmw_vmci/vmci_queue_pair.c | 6 ++-
drivers/mmc/host/sdhci-omap.c | 6 ++-
drivers/mtd/ar7part.c | 2 +-
drivers/mtd/bcm47xxpart.c | 2 +-
drivers/mtd/chips/cfi_cmdset_0001.c | 9 ++--
drivers/mtd/chips/cfi_cmdset_0002.c | 7 +--
drivers/mtd/chips/cfi_cmdset_0020.c | 5 +-
drivers/mtd/devices/docg3.c | 4 +-
drivers/mtd/ftl.c | 15 +++---
drivers/mtd/inftlmount.c | 6 ++-
drivers/mtd/lpddr/lpddr_cmds.c | 2 +-
drivers/mtd/maps/physmap_of_core.c | 4 +-
drivers/mtd/maps/vmu-flash.c | 8 ++--
drivers/mtd/mtdconcat.c | 5 +-
drivers/mtd/mtdoops.c | 6 ++-
drivers/mtd/mtdswap.c | 6 +--
drivers/mtd/nand/onenand/onenand_base.c | 6 ++-
drivers/mtd/nand/raw/nand_bch.c | 2 +-
drivers/mtd/nand/raw/nandsim.c | 7 +--
drivers/mtd/nand/raw/qcom_nandc.c | 4 +-
drivers/mtd/nand/raw/s3c2410.c | 2 +-
drivers/mtd/nftlmount.c | 7 ++-
drivers/mtd/ofpart.c | 4 +-
drivers/mtd/parsers/parser_trx.c | 2 +-
drivers/mtd/parsers/sharpslpart.c | 5 +-
drivers/mtd/rfd_ftl.c | 3 +-
drivers/mtd/sm_ftl.c | 6 +--
drivers/mtd/ssfdc.c | 5 +-
drivers/mtd/tests/pagetest.c | 2 +-
drivers/mtd/tests/stresstest.c | 2 +-
drivers/mtd/ubi/eba.c | 14 +++---
drivers/mtd/ubi/wl.c | 2 +-
drivers/net/bonding/bond_main.c | 2 +-
drivers/net/can/grcan.c | 4 +-
drivers/net/can/slcan.c | 2 +-
drivers/net/dsa/b53/b53_common.c | 8 ++--
drivers/net/ethernet/amazon/ena/ena_ethtool.c | 8 ++--
drivers/net/ethernet/amd/lance.c | 8 ++--
drivers/net/ethernet/atheros/atl1c/atl1c_ethtool.c | 4 +-
drivers/net/ethernet/atheros/atl1e/atl1e_ethtool.c | 4 +-
drivers/net/ethernet/atheros/atlx/atl2.c | 4 +-
drivers/net/ethernet/broadcom/bcm63xx_enet.c | 4 +-
drivers/net/ethernet/broadcom/bnx2.c | 9 ++--
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c | 13 +++---
drivers/net/ethernet/broadcom/bnxt/bnxt_vfr.c | 4 +-
drivers/net/ethernet/broadcom/cnic.c | 10 ++--
drivers/net/ethernet/broadcom/tg3.c | 5 +-
drivers/net/ethernet/brocade/bna/bnad.c | 4 +-
drivers/net/ethernet/calxeda/xgmac.c | 4 +-
drivers/net/ethernet/cavium/liquidio/octeon_droq.c | 9 ++--
.../net/ethernet/cavium/liquidio/request_manager.c | 5 +-
drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 4 +-
drivers/net/ethernet/chelsio/cxgb4/clip_tbl.c | 2 +-
drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 2 +-
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 10 ++--
drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32.c | 3 +-
drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c | 4 +-
drivers/net/ethernet/chelsio/cxgb4/sge.c | 2 +-
drivers/net/ethernet/cortina/gemini.c | 4 +-
drivers/net/ethernet/ethoc.c | 3 +-
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 2 +-
drivers/net/ethernet/freescale/ucc_geth.c | 12 ++---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c | 4 +-
drivers/net/ethernet/hisilicon/hns/hns_enet.c | 3 +-
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 6 ++-
drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c | 5 +-
drivers/net/ethernet/ibm/ibmveth.c | 2 +-
drivers/net/ethernet/intel/e1000/e1000_ethtool.c | 4 +-
drivers/net/ethernet/intel/e1000e/ethtool.c | 4 +-
drivers/net/ethernet/intel/e1000e/netdev.c | 2 +-
drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c | 2 +-
drivers/net/ethernet/intel/igb/igb_ethtool.c | 16 +++----
drivers/net/ethernet/intel/igb/igb_main.c | 7 +--
drivers/net/ethernet/intel/ixgb/ixgb_ethtool.c | 5 +-
drivers/net/ethernet/intel/ixgb/ixgb_main.c | 5 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 4 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 +-
drivers/net/ethernet/intel/ixgbevf/ethtool.c | 8 ++--
drivers/net/ethernet/jme.c | 10 ++--
drivers/net/ethernet/mellanox/mlx4/alloc.c | 4 +-
drivers/net/ethernet/mellanox/mlx4/cmd.c | 21 +++++----
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 20 ++++----
drivers/net/ethernet/mellanox/mlx4/eq.c | 5 +-
drivers/net/ethernet/mellanox/mlx4/icm.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/main.c | 5 +-
.../net/ethernet/mellanox/mlx4/resource_tracker.c | 26 ++++++-----
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 16 +++----
.../net/ethernet/mellanox/mlx5/core/fpga/conn.c | 10 ++--
.../net/ethernet/mellanox/mlx5/core/fpga/ipsec.c | 2 +-
.../net/ethernet/mellanox/mlx5/core/lib/clock.c | 5 +-
.../net/ethernet/mellanox/mlxsw/spectrum_qdisc.c | 3 +-
drivers/net/ethernet/micrel/ksz884x.c | 2 +-
drivers/net/ethernet/moxa/moxart_ether.c | 8 ++--
drivers/net/ethernet/neterion/vxge/vxge-config.c | 21 +++++----
drivers/net/ethernet/neterion/vxge/vxge-main.c | 4 +-
drivers/net/ethernet/netronome/nfp/abm/main.c | 2 +-
.../net/ethernet/netronome/nfp/flower/metadata.c | 3 +-
drivers/net/ethernet/ni/nixge.c | 5 +-
drivers/net/ethernet/nvidia/forcedeth.c | 6 ++-
.../net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 2 +-
drivers/net/ethernet/pasemi/pasemi_mac.c | 10 ++--
drivers/net/ethernet/qlogic/qed/qed_debug.c | 5 +-
drivers/net/ethernet/qlogic/qed/qed_dev.c | 16 +++----
drivers/net/ethernet/qlogic/qed/qed_init_ops.c | 4 +-
drivers/net/ethernet/qlogic/qed/qed_l2.c | 4 +-
drivers/net/ethernet/qlogic/qed/qed_mcp.c | 6 +--
drivers/net/ethernet/qlogic/qede/qede_filter.c | 5 +-
.../net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c | 5 +-
drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 15 +++---
.../ethernet/qlogic/qlcnic/qlcnic_sriov_common.c | 8 ++--
drivers/net/ethernet/qlogic/qlge/qlge_main.c | 3 +-
drivers/net/ethernet/sfc/ef10.c | 3 +-
drivers/net/ethernet/sfc/falcon/farch.c | 3 +-
drivers/net/ethernet/sfc/farch.c | 3 +-
drivers/net/ethernet/socionext/netsec.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c | 4 +-
drivers/net/ethernet/ti/cpsw.c | 9 ++--
drivers/net/ethernet/ti/netcp_ethss.c | 24 +++++-----
drivers/net/ethernet/toshiba/ps3_gelic_wireless.c | 5 +-
drivers/net/gtp.c | 6 ++-
drivers/net/hippi/rrunner.c | 2 +-
drivers/net/phy/dp83640.c | 5 +-
drivers/net/phy/phy_led_triggers.c | 6 +--
drivers/net/ppp/bsd_comp.c | 4 +-
drivers/net/ppp/pptp.c | 2 +-
drivers/net/slip/slip.c | 2 +-
drivers/net/team/team.c | 5 +-
drivers/net/usb/asix_common.c | 8 ++--
drivers/net/usb/ax88179_178a.c | 4 +-
drivers/net/usb/smsc95xx.c | 2 +-
drivers/net/usb/usbnet.c | 4 +-
drivers/net/virtio_net.c | 12 ++---
drivers/net/wan/fsl_ucc_hdlc.c | 6 ++-
drivers/net/wireless/ath/ath10k/htt_rx.c | 2 +-
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 2 +-
drivers/net/wireless/ath/ath5k/debug.c | 2 +-
drivers/net/wireless/ath/ath5k/phy.c | 3 +-
drivers/net/wireless/ath/ath6kl/cfg80211.c | 2 +-
drivers/net/wireless/ath/ath9k/ar9003_paprd.c | 2 +-
drivers/net/wireless/ath/ath9k/hw.c | 4 +-
drivers/net/wireless/ath/carl9170/main.c | 7 +--
drivers/net/wireless/broadcom/b43/phy_n.c | 2 +-
drivers/net/wireless/broadcom/b43legacy/main.c | 4 +-
.../wireless/broadcom/brcm80211/brcmfmac/msgbuf.c | 5 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/p2p.c | 2 +-
.../wireless/broadcom/brcm80211/brcmsmac/main.c | 7 +--
.../broadcom/brcm80211/brcmsmac/phy/phy_lcn.c | 8 ++--
.../broadcom/brcm80211/brcmsmac/phy/phy_n.c | 5 +-
drivers/net/wireless/cisco/airo.c | 2 +-
drivers/net/wireless/intel/ipw2x00/ipw2100.c | 11 +++--
drivers/net/wireless/intel/ipw2x00/ipw2200.c | 10 ++--
drivers/net/wireless/intel/iwlegacy/common.c | 13 +++---
drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 2 +-
drivers/net/wireless/intersil/hostap/hostap_info.c | 5 +-
.../net/wireless/intersil/hostap/hostap_ioctl.c | 4 +-
drivers/net/wireless/intersil/p54/eeprom.c | 12 +++--
drivers/net/wireless/intersil/prism54/oid_mgt.c | 2 +-
.../net/wireless/marvell/mwifiex/11n_rxreorder.c | 4 +-
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 4 +-
drivers/net/wireless/marvell/mwifiex/sdio.c | 9 ++--
drivers/net/wireless/mediatek/mt76/mac80211.c | 2 +-
drivers/net/wireless/quantenna/qtnfmac/commands.c | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2x00debug.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/efuse.c | 4 +-
drivers/net/wireless/realtek/rtlwifi/usb.c | 2 +-
drivers/net/wireless/st/cw1200/queue.c | 10 ++--
drivers/net/wireless/st/cw1200/scan.c | 6 +--
drivers/net/wireless/zydas/zd1211rw/zd_mac.c | 3 +-
drivers/net/xen-netback/xenbus.c | 4 +-
drivers/nfc/fdp/i2c.c | 4 +-
drivers/ntb/hw/amd/ntb_hw_amd.c | 4 +-
drivers/ntb/hw/intel/ntb_hw_intel.c | 4 +-
drivers/ntb/ntb_transport.c | 4 +-
drivers/nvmem/rockchip-efuse.c | 6 ++-
drivers/nvmem/sunxi_sid.c | 2 +-
drivers/of/platform.c | 2 +-
drivers/of/unittest.c | 2 +-
drivers/opp/ti-opp-supply.c | 4 +-
drivers/oprofile/event_buffer.c | 2 +-
drivers/pci/cadence/pcie-cadence-ep.c | 3 +-
drivers/pci/dwc/pci-dra7xx.c | 4 +-
drivers/pci/dwc/pcie-designware-ep.c | 8 ++--
drivers/pci/host/pcie-rockchip-ep.c | 2 +-
drivers/pci/msi.c | 4 +-
drivers/pci/pci-sysfs.c | 2 +-
drivers/pcmcia/cistpl.c | 4 +-
drivers/pcmcia/pd6729.c | 2 +-
drivers/pinctrl/bcm/pinctrl-bcm2835.c | 4 +-
drivers/pinctrl/berlin/berlin.c | 10 ++--
drivers/pinctrl/freescale/pinctrl-imx.c | 18 +++++---
drivers/pinctrl/freescale/pinctrl-imx1-core.c | 23 ++++-----
drivers/pinctrl/freescale/pinctrl-mxs.c | 20 ++++----
drivers/pinctrl/mvebu/pinctrl-armada-37xx.c | 21 +++++----
drivers/pinctrl/mvebu/pinctrl-armada-xp.c | 4 +-
drivers/pinctrl/mvebu/pinctrl-mvebu.c | 16 ++++---
drivers/pinctrl/pinctrl-at91-pio4.c | 39 +++++++++-------
drivers/pinctrl/pinctrl-at91.c | 34 +++++++++-----
drivers/pinctrl/pinctrl-axp209.c | 7 +--
drivers/pinctrl/pinctrl-digicolor.c | 5 +-
drivers/pinctrl/pinctrl-ingenic.c | 4 +-
drivers/pinctrl/pinctrl-lantiq.c | 3 +-
drivers/pinctrl/pinctrl-lpc18xx.c | 5 +-
drivers/pinctrl/pinctrl-ocelot.c | 3 +-
drivers/pinctrl/pinctrl-rockchip.c | 24 ++++++----
drivers/pinctrl/pinctrl-single.c | 26 ++++++-----
drivers/pinctrl/pinctrl-st.c | 31 +++++++------
drivers/pinctrl/pinctrl-xway.c | 4 +-
drivers/pinctrl/samsung/pinctrl-exynos.c | 5 +-
drivers/pinctrl/samsung/pinctrl-samsung.c | 17 ++++---
drivers/pinctrl/sh-pfc/core.c | 6 +--
drivers/pinctrl/sh-pfc/gpio.c | 7 +--
drivers/pinctrl/sh-pfc/pinctrl.c | 8 ++--
drivers/pinctrl/sirf/pinctrl-sirf.c | 2 +-
drivers/pinctrl/spear/pinctrl-plgpio.c | 4 +-
drivers/pinctrl/spear/pinctrl-spear.c | 2 +-
drivers/pinctrl/sprd/pinctrl-sprd.c | 19 ++++----
drivers/pinctrl/sunxi/pinctrl-sunxi.c | 22 +++++----
drivers/pinctrl/tegra/pinctrl-tegra.c | 6 +--
drivers/pinctrl/ti/pinctrl-ti-iodelay.c | 6 +--
drivers/pinctrl/vt8500/pinctrl-wmt.c | 2 +-
drivers/pinctrl/zte/pinctrl-zx.c | 6 +--
drivers/platform/mellanox/mlxreg-hotplug.c | 3 +-
drivers/platform/x86/alienware-wmi.c | 6 +--
drivers/platform/x86/intel_ips.c | 12 ++---
drivers/platform/x86/panasonic-laptop.c | 2 +-
drivers/platform/x86/thinkpad_acpi.c | 2 +-
drivers/power/supply/charger-manager.c | 29 +++++++-----
drivers/power/supply/power_supply_core.c | 4 +-
drivers/power/supply/wm97xx_battery.c | 2 +-
drivers/power/supply/z2_battery.c | 2 +-
drivers/powercap/powercap_sys.c | 9 ++--
drivers/pwm/pwm-lp3943.c | 2 +-
drivers/rapidio/devices/rio_mport_cdev.c | 2 +-
drivers/rapidio/rio-scan.c | 6 +--
drivers/regulator/act8865-regulator.c | 7 +--
drivers/regulator/as3711-regulator.c | 6 ++-
drivers/regulator/bcm590xx-regulator.c | 6 ++-
drivers/regulator/da9063-regulator.c | 4 +-
drivers/regulator/gpio-regulator.c | 10 ++--
drivers/regulator/max1586.c | 6 ++-
drivers/regulator/max8660.c | 6 ++-
drivers/regulator/max8997-regulator.c | 5 +-
drivers/regulator/max8998.c | 5 +-
drivers/regulator/mc13xxx-regulator-core.c | 2 +-
drivers/regulator/pbias-regulator.c | 5 +-
drivers/regulator/rc5t583-regulator.c | 6 ++-
drivers/regulator/s2mps11.c | 6 +--
drivers/regulator/s5m8767.c | 10 ++--
drivers/regulator/ti-abb-regulator.c | 4 +-
drivers/regulator/tps65090-regulator.c | 10 ++--
drivers/regulator/tps65217-regulator.c | 5 +-
drivers/regulator/tps65218-regulator.c | 5 +-
drivers/regulator/tps65910-regulator.c | 18 +++++---
drivers/regulator/tps80031-regulator.c | 4 +-
drivers/reset/reset-ti-syscon.c | 3 +-
drivers/s390/block/dasd_eer.c | 4 +-
drivers/s390/block/dcssblk.c | 6 +--
drivers/s390/char/keyboard.c | 2 +-
drivers/s390/char/sclp_sd.c | 2 +-
drivers/s390/char/tty3270.c | 3 +-
drivers/s390/char/vmur.c | 2 +-
drivers/s390/char/zcore.c | 2 +-
drivers/s390/cio/qdio_setup.c | 2 +-
drivers/s390/cio/qdio_thinint.c | 5 +-
drivers/s390/crypto/pkey_api.c | 8 ++--
drivers/s390/net/ctcm_main.c | 2 +-
drivers/s390/net/qeth_core_main.c | 27 ++++++-----
drivers/scsi/BusLogic.c | 2 +-
drivers/scsi/aacraid/aachba.c | 2 +-
drivers/scsi/aacraid/linit.c | 4 +-
drivers/scsi/aha1542.c | 3 +-
drivers/scsi/aic7xxx/aic79xx_core.c | 3 +-
drivers/scsi/aic7xxx/aic7xxx_core.c | 4 +-
drivers/scsi/aic94xx/aic94xx_hwi.c | 12 +++--
drivers/scsi/aic94xx/aic94xx_init.c | 2 +-
drivers/scsi/arm/queue.c | 2 +-
drivers/scsi/be2iscsi/be_main.c | 54 ++++++++++++----------
drivers/scsi/bfa/bfad_attr.c | 2 +-
drivers/scsi/bfa/bfad_bsg.c | 5 +-
drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 2 +-
drivers/scsi/bnx2fc/bnx2fc_io.c | 8 ++--
drivers/scsi/csiostor/csio_wr.c | 4 +-
drivers/scsi/esas2r/esas2r_init.c | 11 +++--
drivers/scsi/fcoe/fcoe_ctlr.c | 4 +-
drivers/scsi/fnic/fnic_debugfs.c | 7 +--
drivers/scsi/fnic/fnic_trace.c | 15 +++---
drivers/scsi/hpsa.c | 36 ++++++++-------
drivers/scsi/ipr.c | 16 ++++---
drivers/scsi/isci/init.c | 8 ++--
drivers/scsi/libiscsi.c | 2 +-
drivers/scsi/libsas/sas_expander.c | 2 +-
drivers/scsi/lpfc/lpfc_init.c | 7 +--
drivers/scsi/lpfc/lpfc_mem.c | 5 +-
drivers/scsi/lpfc/lpfc_sli.c | 50 +++++++++-----------
drivers/scsi/lpfc/lpfc_vport.c | 2 +-
drivers/scsi/mac53c94.c | 5 +-
drivers/scsi/megaraid.c | 3 +-
drivers/scsi/megaraid/megaraid_mm.c | 10 ++--
drivers/scsi/megaraid/megaraid_sas_base.c | 8 ++--
drivers/scsi/megaraid/megaraid_sas_fusion.c | 12 +++--
drivers/scsi/osst.c | 8 ++--
drivers/scsi/pm8001/pm8001_ctl.c | 2 +-
drivers/scsi/pmcraid.c | 5 +-
drivers/scsi/qedi/qedi_main.c | 2 +-
drivers/scsi/qla2xxx/qla_init.c | 10 ++--
drivers/scsi/qla2xxx/qla_isr.c | 5 +-
drivers/scsi/qla2xxx/qla_nx.c | 2 +-
drivers/scsi/qla2xxx/qla_os.c | 14 +++---
drivers/scsi/qla2xxx/qla_target.c | 10 ++--
drivers/scsi/qla2xxx/tcm_qla2xxx.c | 4 +-
drivers/scsi/qla4xxx/ql4_nx.c | 2 +-
drivers/scsi/scsi_debug.c | 5 +-
drivers/scsi/sd_zbc.c | 2 +-
drivers/scsi/ses.c | 2 +-
drivers/scsi/sg.c | 2 +-
drivers/scsi/smartpqi/smartpqi_init.c | 10 ++--
drivers/scsi/st.c | 5 +-
drivers/scsi/ufs/ufshcd-pltfrm.c | 4 +-
drivers/scsi/ufs/ufshcd.c | 4 +-
drivers/scsi/virtio_scsi.c | 7 +--
drivers/sh/clk/cpg.c | 2 +-
drivers/sh/intc/core.c | 10 ++--
drivers/sh/maple/maple.c | 2 +-
drivers/slimbus/qcom-ctrl.c | 2 +-
drivers/soc/bcm/raspberrypi-power.c | 6 ++-
drivers/soc/fsl/qbman/qman.c | 5 +-
drivers/soc/mediatek/mtk-scpsys.c | 8 ++--
drivers/soc/ti/knav_qmss_acc.c | 6 +--
drivers/spi/spi-davinci.c | 7 +--
drivers/spi/spi-ep93xx.c | 4 +-
drivers/spi/spi-gpio.c | 5 +-
drivers/spi/spi-imx.c | 5 +-
drivers/spi/spi-oc-tiny.c | 4 +-
drivers/spi/spi-pl022.c | 2 +-
drivers/spi/spi.c | 2 +-
drivers/staging/android/ion/ion_heap.c | 3 +-
drivers/staging/greybus/audio_topology.c | 2 +-
drivers/staging/greybus/camera.c | 5 +-
drivers/staging/media/imx/imx-media-dev.c | 6 +--
drivers/staging/media/zoran/zoran_driver.c | 5 +-
drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c | 26 +++++++----
drivers/staging/rtl8188eu/core/rtw_mlme.c | 2 +-
drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c | 5 +-
drivers/staging/rtl8192u/r8192U_core.c | 4 +-
drivers/staging/rtl8723bs/core/rtw_mlme.c | 2 +-
drivers/staging/rtlwifi/efuse.c | 4 +-
drivers/staging/rts5208/ms.c | 2 +-
drivers/staging/rts5208/rtsx_chip.c | 6 +--
drivers/staging/unisys/visorhba/visorhba_main.c | 2 +-
drivers/target/target_core_transport.c | 4 +-
drivers/target/target_core_user.c | 5 +-
drivers/thermal/int340x_thermal/acpi_thermal_rel.c | 4 +-
.../thermal/int340x_thermal/int340x_thermal_zone.c | 7 +--
drivers/thermal/of-thermal.c | 4 +-
drivers/thermal/tegra/soctherm.c | 8 ++--
drivers/thermal/thermal-generic-adc.c | 5 +-
drivers/thermal/x86_pkg_temp_thermal.c | 3 +-
drivers/tty/ehv_bytechan.c | 2 +-
drivers/tty/goldfish.c | 5 +-
drivers/tty/hvc/hvc_iucv.c | 2 +-
drivers/tty/hvc/hvcs.c | 3 +-
drivers/tty/isicom.c | 2 +-
drivers/tty/serial/atmel_serial.c | 5 +-
drivers/tty/serial/pch_uart.c | 2 +-
drivers/tty/serial/rp2.c | 2 +-
drivers/tty/serial/serial_core.c | 2 +-
drivers/tty/serial/sunsab.c | 5 +-
drivers/tty/vt/consolemap.c | 7 +--
drivers/tty/vt/keyboard.c | 4 +-
drivers/tty/vt/selection.c | 3 +-
drivers/uio/uio_pruss.c | 2 +-
drivers/usb/core/devio.c | 7 +--
drivers/usb/core/hub.c | 2 +-
drivers/usb/core/message.c | 6 +--
drivers/usb/dwc2/hcd.c | 11 +++--
drivers/usb/gadget/udc/atmel_usba_udc.c | 2 +-
drivers/usb/gadget/udc/bdc/bdc_ep.c | 6 +--
drivers/usb/gadget/udc/fsl_udc_core.c | 2 +-
drivers/usb/gadget/udc/renesas_usb3.c | 3 +-
drivers/usb/host/ehci-sched.c | 5 +-
drivers/usb/host/fhci-tds.c | 2 +-
drivers/usb/host/imx21-hcd.c | 4 +-
drivers/usb/host/ohci-dbg.c | 2 +-
drivers/usb/host/xhci-mem.c | 4 +-
drivers/usb/misc/ldusb.c | 9 +++-
drivers/usb/misc/sisusbvga/sisusb_con.c | 2 +-
drivers/usb/mon/mon_bin.c | 3 +-
drivers/usb/renesas_usbhs/mod_gadget.c | 2 +-
drivers/usb/renesas_usbhs/pipe.c | 3 +-
drivers/usb/serial/iuu_phoenix.c | 4 +-
drivers/usb/storage/alauda.c | 2 +-
drivers/usb/storage/ene_ub6250.c | 16 +++++--
drivers/usb/storage/sddr09.c | 4 +-
drivers/usb/storage/sddr55.c | 6 +--
drivers/usb/wusbcore/wa-rpipe.c | 3 +-
drivers/uwb/est.c | 2 +-
drivers/uwb/i1480/dfu/usb.c | 2 +-
drivers/vhost/net.c | 8 ++--
drivers/vhost/scsi.c | 17 ++++---
drivers/vhost/test.c | 2 +-
drivers/vhost/vhost.c | 14 ++++--
drivers/vhost/vringh.c | 2 +-
drivers/video/backlight/adp8860_bl.c | 2 +-
drivers/video/backlight/adp8870_bl.c | 2 +-
drivers/video/backlight/lp855x_bl.c | 2 +-
drivers/video/console/sticore.c | 2 +-
drivers/video/fbdev/au1100fb.c | 2 +-
drivers/video/fbdev/broadsheetfb.c | 2 +-
drivers/video/fbdev/core/bitblit.c | 4 +-
drivers/video/fbdev/core/fbcon.c | 3 +-
drivers/video/fbdev/core/fbcon_ccw.c | 7 +--
drivers/video/fbdev/core/fbcon_cw.c | 7 +--
drivers/video/fbdev/core/fbcon_rotate.c | 2 +-
drivers/video/fbdev/core/fbcon_ud.c | 4 +-
drivers/video/fbdev/core/fbmem.c | 7 +--
drivers/video/fbdev/core/fbmon.c | 9 ++--
drivers/video/fbdev/imxfb.c | 2 +-
drivers/video/fbdev/mb862xx/mb862xxfb_accel.c | 2 +-
drivers/video/fbdev/mmp/fb/mmpfb.c | 4 +-
drivers/video/fbdev/mxsfb.c | 2 +-
drivers/video/fbdev/nvidia/nvidia.c | 2 +-
drivers/video/fbdev/omap2/omapfb/dss/manager.c | 4 +-
drivers/video/fbdev/omap2/omapfb/dss/overlay.c | 4 +-
drivers/video/fbdev/omap2/omapfb/vrfb.c | 4 +-
drivers/video/fbdev/pvr2fb.c | 2 +-
drivers/video/fbdev/riva/fbdev.c | 2 +-
drivers/video/fbdev/uvesafb.c | 10 ++--
drivers/video/fbdev/via/viafbdev.c | 3 +-
drivers/video/fbdev/w100fb.c | 3 +-
drivers/video/fbdev/xen-fbfront.c | 2 +-
drivers/video/of_display_timing.c | 5 +-
drivers/virt/fsl_hypervisor.c | 2 +-
drivers/virt/vboxguest/vboxguest_core.c | 7 +--
drivers/virtio/virtio_pci_common.c | 7 +--
drivers/virtio/virtio_ring.c | 2 +-
drivers/xen/arm-device.c | 6 +--
drivers/xen/evtchn.c | 2 +-
drivers/xen/grant-table.c | 7 +--
drivers/xen/xen-pciback/pciback_ops.c | 2 +-
fs/9p/fid.c | 2 +-
fs/adfs/super.c | 2 +-
fs/afs/cmservice.c | 7 +--
fs/binfmt_elf.c | 4 +-
fs/binfmt_elf_fdpic.c | 3 +-
fs/block_dev.c | 3 +-
fs/btrfs/check-integrity.c | 4 +-
fs/ceph/addr.c | 11 +++--
fs/ceph/mds_client.c | 5 +-
fs/cifs/asn1.c | 2 +-
fs/cifs/cifsacl.c | 4 +-
fs/cifs/cifssmb.c | 2 +-
fs/cifs/file.c | 2 +-
fs/cifs/inode.c | 2 +-
fs/cifs/misc.c | 4 +-
fs/cifs/smb2pdu.c | 6 +--
fs/cifs/transport.c | 8 ++--
fs/dlm/lockspace.c | 2 +-
fs/exofs/inode.c | 4 +-
fs/ext2/super.c | 4 +-
fs/ext4/extents.c | 8 ++--
fs/ext4/resize.c | 10 ++--
fs/ext4/super.c | 6 +--
fs/f2fs/checkpoint.c | 3 +-
fs/f2fs/file.c | 6 ++-
fs/f2fs/node.c | 12 +++--
fs/f2fs/segment.c | 15 ++++--
fs/f2fs/super.c | 20 +++++---
fs/fat/namei_vfat.c | 2 +-
fs/fuse/dev.c | 15 ++++--
fs/gfs2/dir.c | 6 +--
fs/gfs2/glock.c | 3 +-
fs/gfs2/quota.c | 2 +-
fs/gfs2/rgrp.c | 5 +-
fs/gfs2/super.c | 2 +-
fs/hpfs/dnode.c | 3 +-
fs/hpfs/map.c | 2 +-
fs/jbd2/revoke.c | 2 +-
fs/jffs2/acl.c | 3 +-
fs/jffs2/acl.h | 1 +
fs/jffs2/wbuf.c | 2 +-
fs/jfs/jfs_dmap.c | 2 +-
fs/jfs/jfs_dtree.c | 9 ++--
fs/jfs/jfs_unicode.c | 2 +-
fs/mbcache.c | 5 +-
fs/namei.c | 4 +-
fs/nfs/flexfilelayout/flexfilelayout.c | 2 +-
fs/nfs/flexfilelayout/flexfilelayoutdev.c | 3 +-
fs/nfsd/export.c | 5 +-
fs/nfsd/nfs4recover.c | 5 +-
fs/nfsd/nfs4state.c | 20 ++++----
fs/nfsd/nfscache.c | 3 +-
fs/ntfs/compress.c | 2 +-
fs/ocfs2/cluster/tcp.c | 2 +-
fs/ocfs2/dlm/dlmdomain.c | 2 +-
fs/ocfs2/journal.c | 2 +-
fs/ocfs2/sysfile.c | 9 ++--
fs/overlayfs/namei.c | 2 +-
fs/proc/base.c | 3 +-
fs/proc/proc_sysctl.c | 2 +-
fs/proc/task_mmu.c | 2 +-
fs/read_write.c | 4 +-
fs/reiserfs/bitmap.c | 2 +-
fs/reiserfs/inode.c | 3 +-
fs/reiserfs/journal.c | 13 ++++--
fs/reiserfs/resize.c | 3 +-
fs/select.c | 2 +-
fs/splice.c | 7 +--
fs/ubifs/journal.c | 5 +-
fs/ubifs/lpt.c | 25 ++++++----
fs/ubifs/super.c | 3 +-
fs/ubifs/tnc.c | 5 +-
fs/ubifs/tnc_commit.c | 5 +-
fs/udf/super.c | 7 +--
fs/ufs/super.c | 4 +-
include/linux/mm.h | 5 ++
include/rdma/ib_verbs.h | 5 +-
ipc/sem.c | 2 +-
kernel/bpf/btf.c | 8 ++--
kernel/bpf/lpm_trie.c | 5 +-
kernel/bpf/verifier.c | 10 ++--
kernel/cgroup/cgroup-v1.c | 4 +-
kernel/cgroup/cpuset.c | 5 +-
kernel/debug/kdb/kdb_main.c | 13 ++++--
kernel/events/ring_buffer.c | 3 +-
kernel/events/uprobes.c | 3 +-
kernel/fail_function.c | 2 +-
kernel/kexec_file.c | 2 +-
kernel/locking/locktorture.c | 14 ++++--
kernel/power/swap.c | 6 +--
kernel/rcu/rcutorture.c | 5 +-
kernel/relay.c | 3 +-
kernel/sched/fair.c | 4 +-
kernel/sched/rt.c | 4 +-
kernel/sched/topology.c | 2 +-
kernel/sysctl.c | 3 +-
kernel/trace/ftrace.c | 28 +++++------
kernel/trace/trace.c | 12 +++--
kernel/trace/trace_events_filter.c | 6 +--
kernel/trace/tracing_map.c | 2 +-
kernel/user_namespace.c | 5 +-
kernel/workqueue.c | 2 +-
lib/argv_split.c | 2 +-
lib/interval_tree_test.c | 5 +-
lib/kfifo.c | 2 +-
lib/lru_cache.c | 2 +-
lib/mpi/mpiutil.c | 4 +-
lib/rbtree_test.c | 2 +-
lib/reed_solomon/reed_solomon.c | 6 +--
lib/sbitmap.c | 2 +-
lib/scatterlist.c | 3 +-
lib/test_firmware.c | 10 ++--
lib/test_kmod.c | 5 +-
lib/test_overflow.c | 2 +-
lib/test_rhashtable.c | 13 ++++--
mm/gup_benchmark.c | 2 +-
mm/huge_memory.c | 4 +-
mm/hugetlb.c | 3 +-
mm/percpu-stats.c | 2 +-
mm/slab.c | 3 +-
mm/slub.c | 19 ++++----
mm/swap_slots.c | 4 +-
mm/swap_state.c | 2 +-
mm/swapfile.c | 5 +-
net/9p/protocol.c | 11 +++--
net/9p/trans_virtio.c | 3 +-
net/atm/mpc.c | 2 +-
net/bluetooth/hci_core.c | 2 +-
net/bluetooth/l2cap_core.c | 2 +-
net/bridge/br_multicast.c | 2 +-
net/bridge/netfilter/ebtables.c | 11 +++--
net/can/bcm.c | 13 ++++--
net/ceph/osdmap.c | 5 +-
net/ceph/pagevec.c | 4 +-
net/core/dev.c | 2 +-
net/core/ethtool.c | 12 ++---
net/core/pktgen.c | 3 +-
net/dcb/dcbnl.c | 3 +-
net/dccp/ccids/ccid2.c | 3 +-
net/ieee802154/nl-phy.c | 2 +-
net/ipv4/fib_frontend.c | 2 +-
net/ipv4/route.c | 5 +-
net/ipv6/icmp.c | 2 +-
net/ipv6/ila/ila_xlat.c | 3 +-
net/mac80211/chan.c | 2 +-
net/mac80211/main.c | 2 +-
net/mac80211/rc80211_minstrel.c | 4 +-
net/mac80211/rc80211_minstrel_ht.c | 4 +-
net/mac80211/scan.c | 2 +-
net/mac80211/util.c | 5 +-
net/netfilter/ipvs/ip_vs_conn.c | 3 +-
net/netfilter/nf_conntrack_proto.c | 3 +-
net/netfilter/nf_nat_core.c | 5 +-
net/netfilter/nf_tables_api.c | 6 +--
net/netfilter/nfnetlink_cthelper.c | 5 +-
net/netfilter/x_tables.c | 2 +-
net/netlink/genetlink.c | 10 ++--
net/netrom/af_netrom.c | 2 +-
net/openvswitch/datapath.c | 5 +-
net/openvswitch/vport.c | 2 +-
net/packet/af_packet.c | 2 +-
net/rds/ib.c | 3 +-
net/rds/ib_cm.c | 6 ++-
net/rds/info.c | 2 +-
net/rose/af_rose.c | 3 +-
net/rxrpc/rxkad.c | 2 +-
net/sched/sch_fq_codel.c | 7 +--
net/sched/sch_hhf.c | 9 ++--
net/sctp/auth.c | 5 +-
net/sctp/protocol.c | 2 +-
net/smc/smc_wr.c | 6 +--
net/sunrpc/auth_gss/auth_gss.c | 3 +-
net/sunrpc/auth_gss/gss_rpc_upcall.c | 2 +-
net/sunrpc/cache.c | 2 +-
net/tipc/netlink_compat.c | 5 +-
net/wireless/nl80211.c | 4 +-
security/apparmor/policy_unpack.c | 2 +-
security/keys/trusted.c | 2 +-
security/selinux/ss/services.c | 2 +-
sound/core/pcm_compat.c | 2 +-
sound/core/pcm_native.c | 4 +-
sound/core/seq/seq_memory.c | 3 +-
sound/core/seq/seq_midi_emul.c | 2 +-
sound/firewire/fireface/ff-protocol-ff400.c | 2 +-
sound/firewire/packets-buffer.c | 2 +-
sound/oss/dmasound/dmasound_core.c | 2 +-
sound/pci/cs46xx/cs46xx_lib.c | 7 +--
sound/pci/cs46xx/dsp_spos.c | 9 ++--
sound/pci/ctxfi/ctatc.c | 18 ++++----
sound/pci/ctxfi/ctdaio.c | 3 +-
sound/pci/ctxfi/ctmixer.c | 5 +-
sound/pci/ctxfi/ctsrc.c | 2 +-
sound/pci/emu10k1/emu10k1_main.c | 9 ++--
sound/pci/emu10k1/emufx.c | 8 ++--
sound/pci/emu10k1/p16v.c | 2 +-
sound/pci/hda/hda_codec.c | 4 +-
sound/pci/hda/hda_proc.c | 5 +-
sound/pci/hda/patch_ca0132.c | 4 +-
sound/pci/maestro3.c | 5 +-
sound/pci/trident/trident_main.c | 4 +-
sound/pci/via82xx.c | 4 +-
sound/pci/via82xx_modem.c | 4 +-
sound/pci/ymfpci/ymfpci_main.c | 4 +-
sound/soc/au1x/dbdma2.c | 4 +-
sound/soc/codecs/hdmi-codec.c | 2 +-
sound/soc/codecs/rt5645.c | 5 +-
sound/soc/codecs/wm8904.c | 5 +-
sound/soc/codecs/wm8958-dsp2.c | 20 ++++----
sound/soc/codecs/wm8994.c | 4 +-
sound/soc/codecs/wm_adsp.c | 2 +-
sound/soc/davinci/davinci-mcasp.c | 14 +++---
sound/soc/generic/audio-graph-card.c | 4 +-
sound/soc/generic/audio-graph-scu-card.c | 4 +-
sound/soc/generic/simple-card.c | 8 ++--
sound/soc/generic/simple-scu-card.c | 4 +-
sound/soc/img/img-i2s-in.c | 4 +-
sound/soc/img/img-i2s-out.c | 4 +-
sound/soc/intel/common/sst-ipc.c | 4 +-
sound/soc/intel/skylake/skl-topology.c | 20 ++++----
sound/soc/mediatek/mt2701/mt2701-afe-pcm.c | 3 +-
sound/soc/pxa/mmp-sspa.c | 4 +-
sound/soc/rockchip/rk3399_gru_sound.c | 2 +-
sound/soc/sh/rcar/cmd.c | 2 +-
sound/soc/sh/rcar/core.c | 4 +-
sound/soc/sh/rcar/ctu.c | 2 +-
sound/soc/sh/rcar/dvc.c | 2 +-
sound/soc/sh/rcar/mix.c | 2 +-
sound/soc/sh/rcar/src.c | 2 +-
sound/soc/sh/rcar/ssi.c | 2 +-
sound/soc/sh/rcar/ssiu.c | 2 +-
sound/soc/soc-core.c | 10 ++--
sound/soc/soc-dapm.c | 2 +-
sound/soc/soc-topology.c | 2 +-
sound/soc/uniphier/aio-cpu.c | 10 ++--
sound/usb/6fire/pcm.c | 10 ++--
sound/usb/caiaq/audio.c | 7 +--
sound/usb/format.c | 5 +-
sound/usb/line6/capture.c | 4 +-
sound/usb/line6/pcm.c | 6 ++-
sound/usb/line6/playback.c | 4 +-
sound/usb/mixer.c | 2 +-
sound/usb/pcm.c | 2 +-
sound/usb/usx2y/usbusx2y.c | 4 +-
sound/usb/usx2y/usbusx2yaudio.c | 7 ++-
virt/kvm/arm/vgic/vgic-v4.c | 2 +-
virt/kvm/kvm_main.c | 3 +-
1201 files changed, 3586 insertions(+), 2796 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 16%]
* Re: [GIT PULL] overflow updates (part 2) for v4.18-rc1
@ 2018-06-13 19:07 72% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-06-13 19:07 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, Dan Carpenter, Silvio Cesare, Matthew Wilcox
On Tue, Jun 12, 2018 at 6:44 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Tue, Jun 12, 2018 at 4:36 PM Kees Cook <keescook@chromium.org> wrote:
>>
>> - Treewide conversions of allocators to use either 2-factor argument
>> variant when available, or array_size() and array3_size() as needed (Kees)
>
> Ok, some of this smells just a tad too much of automation, but I've
> done the pull and it's going through my build tests.
Thanks! Yeah, I tried to beat sense into it to avoid REALLY dumb
things that just looked terrible.
> In some of the cases it turns a compile-time constant into a function
> call, ie this just makes for bigger and slower code for no reason
> what-so-ever.
>
> - ch->tx_array = vzalloc(MIC_DMA_DESC_RX_SIZE * sizeof(*ch->tx_array));
> + ch->tx_array = vzalloc(array_size(MIC_DMA_DESC_RX_SIZE,
> + sizeof(*ch->tx_array)));
>
> At least in the kzalloc/kcalloc conversion it results in more legible code.
I did try to convince my scripting to avoid the less sane conversions,
but as you saw there were still some that fell through. In the end, I
decided to let it stand since because Rasmus's code is so careful, if
array_size() processes constant expressions, it'll produce a constant
expression, so the machine code result actually isn't worse in these
cases. Using the above example, it's the same as without array_size():
struct dma_async_tx_descriptor is 72 bytes
/* size: 72, cachelines: 2, members: 10 */
MIC_DMA_DESC_RX_SIZE is 131068
#define MIC_DMA_DESC_RX_SIZE (128 * 1024 - 4)
131068 * 72 = 0x8ffee0
vzalloc(array_size(MIC_DMA_DESC_RX_SIZE, sizeof(*ch->tx_array)))
ffffffff815e87d0: bf e0 fe 8f 00 mov $0x8ffee0,%edi
ffffffff815e87d5: e8 c6 4b be ff callq <vzalloc>
The same is true for each of these all-constants forms, with each
resolving to the same machine code in my tests:
kmalloc(16 * PAGE_SIZE, GFP_KERNEL)
kmalloc_array(16, PAGE_SIZE, GFP_KERNEL)
kmalloc(array_size(16, PAGE_SIZE), GFP_KERNEL)
16 * 4096 = 0x10000
ffffffff8179810e: ba 04 00 00 00 mov $0x4,%edx
ffffffff81798113: be c0 00 60 00 mov $0x6000c0,%esi
ffffffff81798118: bf 00 00 01 00 mov $0x10000,%edi
ffffffff8179811d: e8 6e b0 a1 ff callq <kmalloc_order_trace>
Obviously, it gets more interesting once there is an actual variable in play:
kmalloc(var * PAGE_SIZE, GFP_KERNEL) does no overflow checking, as
expected, and is what I wanted to eliminate from the kernel:
ffffffff8179810e: 48 63 3d 93 f4 14 01 movslq 0x114f493(%rip),%rdi
ffffffff81798115: be c0 00 60 00 mov $0x6000c0,%esi
ffffffff8179811a: 48 c1 e7 0c shl $0xc,%rdi
ffffffff8179811e: e8 1d af a4 ff callq <__kmalloc>
kmalloc_array(var, PAGE_SIZE, GFP_KERNEL) has its builtin overflow
checking and returns NULL:
ffffffff8179810e: 48 63 05 93 f4 14 01 movslq 0x114f493(%rip),%rax
ffffffff81798115: bf 00 10 00 00 mov $0x1000,%edi
ffffffff8179811a: 48 f7 e7 mul %rdi
ffffffff8179811d: 48 89 c7 mov %rax,%rdi
ffffffff81798120: 70 18 jo ffffffff8179813a
ffffffff81798122: be c0 00 60 00 mov $0x6000c0,%esi
ffffffff81798127: e8 14 af a4 ff callq <__kmalloc>
ffffffff8179812c: 48 89 05 ad ea fd 01 mov %rax,0x1fdeaad(%rip)
ffffffff81798133: 48 83 c4 08 add $0x8,%rsp
ffffffff81798137: 5b pop %rbx
ffffffff81798138: 5d pop %rbp
ffffffff81798139: c3 retq
ffffffff8179813a: 31 c0 xor %eax,%eax
ffffffff8179813c: eb ee jmp ffffffff8179812c
kmalloc(array_size(var, PAGE_SIZE), GFP_KERNEL), (not that this form
should be used, but just to illustrate) performs the saturation
instead of the NULL return:
ffffffff8179810e: 48 63 05 93 f4 14 01 movslq 0x114f493(%rip),%rax
ffffffff81798115: bf 00 10 00 00 mov $0x1000,%edi
ffffffff8179811a: 48 f7 e7 mul %rdi
ffffffff8179811d: 48 89 c7 mov %rax,%rdi
ffffffff81798120: 70 18 jo ffffffff8179813a
ffffffff81798122: be c0 00 60 00 mov $0x6000c0,%esi
ffffffff81798127: e8 14 af a4 ff callq <__kmalloc>
ffffffff8179812c: 48 89 05 ad ea fd 01 mov %rax,0x1fdeaad(%rip)
ffffffff81798133: 48 83 c4 08 add $0x8,%rsp
ffffffff81798137: 5b pop %rbx
ffffffff81798138: 5d pop %rbp
ffffffff81798139: c3 retq
ffffffff8179813a: ba 34 00 00 00 mov $0x34,%edx
ffffffff8179813f: be c0 00 60 00 mov $0x6000c0,%esi
ffffffff81798144: 48 83 cf ff or $0xffffffffffffffff,%rdi
ffffffff81798148: e8 43 b0 a1 ff callq <kmalloc_order_trace>
ffffffff8179814d: eb dd jmp ffffffff8179812c
> To make up for it, there's some conversions *away* from nonsensical expressions:
>
> - hc_name = kzalloc(sizeof(char) * (HSMMC_NAME_LEN + 1), GFP_KERNEL);
> + hc_name = kzalloc(HSMMC_NAME_LEN + 1, GFP_KERNEL);
Yeah, I tried to catch these and some other masked cases. Coccinelle
didn't seem to have a consistent isomorphism for (sizeof(thing)) vs
sizeof(thing), so I also tried to drop redundant parens.
> but I _really_ think you were way too eager to move to array_size()
> even when it made no sense what-so-ever.
>
> But at least with the kcalloc()/kmalloc_array() conversions now
> preferred, those crazy cases are now a minority rather than "most of
> the patch makes code worse".
Net improvement was my goal, yes! :)
> I am *not* looking forward to the conflicts this causes, but maybe it
> won't be too bad. Fingers crossed.
Hopefully it shouldn't be too bad, but that's why I tried to perform
the conversion as late in -rc1 as possible, etc.
Thanks again for the pull! I'll keep my eyes out for new cases that
need conversion. Hopefully we can enhance checkpatch to yell more
loudly too. :)
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 72%]
* [GIT PULL] usercopy fix for v4.18-rc8
@ 2018-08-04 15:04 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-08-04 15:04 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Bart Massey, Dave Kleikamp, jfs-discussion,
Kees Cook, stable
Hi,
Please pull this usercopy fix for v4.18-rc8. Bart Massey discovered that
the usercopy whitelist for JFS was incomplete: the inline inode data may
intentionally "overflow" into the neighboring "extended area", so the
size of the whitelist needed to be raised to include the neighboring
field.
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 tags/usercopy-fix-v4.18-rc8
for you to fetch changes up to 961b33c244e5ba1543ae26270a1ba29f29c2db83:
jfs: Fix usercopy whitelist for inline inode data (2018-08-04 07:53:46 -0700)
----------------------------------------------------------------
- Fix JFS usercopy whitelist (it needed to cover neighboring field too) for
"overflow" inline inode data.
----------------------------------------------------------------
Kees Cook (1):
jfs: Fix usercopy whitelist for inline inode data
fs/jfs/jfs_dinode.h | 7 +++++++
fs/jfs/jfs_incore.h | 1 +
fs/jfs/super.c | 3 +--
3 files changed, 9 insertions(+), 2 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] hardened-usercopy updates for v4.19-rc1
@ 2018-08-13 20:33 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-08-13 20:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Chris von Recklinghausen, Kamal Mostafa
Hi Linus,
Please pull these hardened-usercopy changes for v4.19-rc1. This cleans
up a minor Kconfig issue and adds a kernel boot option for disabling
hardened usercopy for distro users that may have corner-case performance
issues (e.g. high bandwidth small-packet UDP traffic).
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 tags/hardened-usercopy-v4.19-rc1
for you to fetch changes up to b5cb15d9372abc9adc4e844c0c1bf594ca6a7695:
usercopy: Allow boot cmdline disabling of hardening (2018-07-04 08:04:52 -0700)
----------------------------------------------------------------
- drop unneeded Kconfig "select BUG" (Kamal Mostafa)
- add "hardened_usercopy=off" rare performance needs (Chris von Recklinghausen)
----------------------------------------------------------------
Chris von Recklinghausen (1):
usercopy: Allow boot cmdline disabling of hardening
Kamal Mostafa (1):
usercopy: Do not select BUG with HARDENED_USERCOPY
Documentation/admin-guide/kernel-parameters.txt | 11 +++++++++++
include/linux/jump_label.h | 6 ++++++
mm/usercopy.c | 25 +++++++++++++++++++++++++
security/Kconfig | 1 -
4 files changed, 42 insertions(+), 1 deletion(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] pstore update for v4.19-rc1
@ 2018-08-13 20:37 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-08-13 20:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Geliang Tang
Hi Linus,
Please pull this pstore change for v4.19-rc1. This cycle has been
very quiet for pstore: the only change is adding awareness of the zstd
compression method.
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 tags/pstore-v4.19-rc1
for you to fetch changes up to 1021bcf44d0e876b10f8739594ad7e6e9c746026:
pstore: add zstd compression support (2018-08-03 18:12:18 -0700)
----------------------------------------------------------------
- Add awareness of zstd compression (Geliang Tang)
----------------------------------------------------------------
Geliang Tang (1):
pstore: add zstd compression support
fs/pstore/Kconfig | 17 ++++++++++++++---
fs/pstore/platform.c | 16 ++++++++++++++++
2 files changed, 30 insertions(+), 3 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] gcc-plugin updates for v4.19-rc1
@ 2018-08-13 21:43 71% Kees Cook
0 siblings, 1 reply; 200+ results
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 tags/gcc-plugins-v4.19-rc1
for you to fetch changes up to b1310d137bc578f0032b6b990628a366d5f0910e:
stackleak: Allow runtime disabling of kernel stack erasing (2018-07-26 09:04:15 -0700)
----------------------------------------------------------------
- Kconfig and Makefile clean ups (Masahiro Yamada, Kees Cook)
- Add STACKLEAK plugin, metrics, docs, knob and x86 hooks (Alexander Popov)
----------------------------------------------------------------
Alexander Popov (7):
gcc-plugins: Clean up the cgraph_create_edge* macros
x86/entry: Add STACKLEAK erasing the kernel stack at the end of syscalls
gcc-plugins: Add STACKLEAK plugin for tracking the kernel stack
lkdtm: Add a test for STACKLEAK
fs/proc: Show STACKLEAK metrics in the /proc file system
doc: self-protection: Add information about STACKLEAK feature
stackleak: Allow runtime disabling of kernel stack erasing
Kees Cook (1):
gcc-plugins: Regularize Makefile.gcc-plugins
Masahiro Yamada (2):
gcc-plugins: remove unused GCC_PLUGIN_SUBDIR
gcc-plugins: split out Kconfig entries to scripts/gcc-plugins/Kconfig
Documentation/security/self-protection.rst | 23 +-
Documentation/sysctl/kernel.txt | 18 ++
Documentation/x86/x86_64/mm.txt | 2 +
arch/Kconfig | 147 +--------
arch/x86/Kconfig | 1 +
arch/x86/entry/calling.h | 14 +
arch/x86/entry/entry_32.S | 7 +
arch/x86/entry/entry_64.S | 3 +
arch/x86/entry/entry_64_compat.S | 5 +
arch/x86/kernel/dumpstack.c | 31 ++
drivers/misc/lkdtm/Makefile | 3 +
drivers/misc/lkdtm/core.c | 3 +
drivers/misc/lkdtm/lkdtm.h | 5 +
drivers/misc/lkdtm/stackleak.c | 146 +++++++++
fs/proc/base.c | 18 ++
include/linux/sched.h | 5 +
include/linux/stackleak.h | 35 +++
kernel/Makefile | 4 +
kernel/fork.c | 3 +
kernel/stackleak.c | 132 ++++++++
kernel/sysctl.c | 15 +-
scripts/Makefile.gcc-plugins | 47 ++-
scripts/gcc-plugins/Kconfig | 196 ++++++++++++
scripts/gcc-plugins/Makefile | 5 -
scripts/gcc-plugins/gcc-common.h | 26 +-
scripts/gcc-plugins/stackleak_plugin.c | 480 +++++++++++++++++++++++++++++
26 files changed, 1195 insertions(+), 179 deletions(-)
create mode 100644 drivers/misc/lkdtm/stackleak.c
create mode 100644 include/linux/stackleak.h
create mode 100644 kernel/stackleak.c
create mode 100644 scripts/gcc-plugins/Kconfig
create mode 100644 scripts/gcc-plugins/stackleak_plugin.c
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 71%]
* Re: [GIT PULL] gcc-plugin updates for v4.19-rc1
@ 2018-08-15 18:35 85% ` Kees Cook
0 siblings, 1 reply; 200+ results
From: Kees Cook @ 2018-08-15 18:35 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, Alexander Popov, Dave Hansen,
Ingo Molnar, Masahiro Yamada, Thomas Gleixner, Tycho Andersen,
Mark Rutland, Laura Abbott, Will Deacon
On Wed, Aug 15, 2018 at 9:41 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Mon, Aug 13, 2018 at 2:43 PM Kees Cook <keescook@chromium.org> wrote:
>>
>> Please pull these gcc-plugin changes for v4.19-rc1.
>
> No.
>
> It adds yet another BUG_ON() without having been merged.
>
> I'm not pulling this. Dammit, have you learnt *nothing*?
I swear I'm doing my best. Are you speaking of
stackleak_check_alloca() or stackleak_erase()? These were both
discussed on the list, and we weren't able to come up with
alternatives: in both cases we're off the stack, and recovery is
seemingly impossible. What would you prefer in these cases? If I need
to take a hard line of "never BUG", how do I handle legitimate system
corruption? (i.e. I have interpreted this as different from narrowing
copy_*_user() usage: if we let execution continue, we'll just crash
somewhere else with likely less information on how to handle it.)
> I'm, disappointed in the whole feature, but I'm also tired of having
> to go and even look for these things.
I am trying to make these patches easier to review. I even made sure
to get Ingo's Ack and Alexander implemented additional features Ingo
suggested, before sending them your way, as Ingo has a very
conservative eye on.
> Then actually *finding* them makes me just pissed off.
I'm sorry we've disappointed you. I've been pushing back on patches
that use BUG (with, I think, good success), but there are cases where
our imagination fails us.
I'd really like to find a way for this plugin to be acceptable, given
the coverage is provides. Even if we solve stack initialization and
finish VLA removal, we still would benefit from something doing
post-syscall stack poisoning just to keep future cache attacks against
the stack minimized.
In the meantime, I will send the gcc-plugin cleanups separately...
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 85%]
* [GIT PULL] gcc-plugin cleanups for v4.19-rc1
@ 2018-08-15 18:40 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-08-15 18:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Alexander Popov, Masahiro Yamada
Hi,
Please pull these gcc-plugin cleanups for v4.19-rc1. This moves the Kconfig
menu around, makes the Makefile more readable, and clean up a function
declaration.
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 tags/gcc-plugin-cleanup-v4.19-rc1
for you to fetch changes up to 45d9a1e3cc45efee6c0ef82b77269d6944d9d8a5:
gcc-plugins: Clean up the cgraph_create_edge* macros (2018-07-24 16:14:06 -0700)
----------------------------------------------------------------
- Kconfig and Makefile clean-ups (Masahiro Yamada, Kees Cook)
- gcc-common.h definition clean-ups (Alexander Popov)
----------------------------------------------------------------
Alexander Popov (1):
gcc-plugins: Clean up the cgraph_create_edge* macros
Kees Cook (1):
gcc-plugins: Regularize Makefile.gcc-plugins
Masahiro Yamada (2):
gcc-plugins: remove unused GCC_PLUGIN_SUBDIR
gcc-plugins: split out Kconfig entries to scripts/gcc-plugins/Kconfig
arch/Kconfig | 146 +--------------------------------------
scripts/Makefile.gcc-plugins | 37 ++++++----
scripts/gcc-plugins/Kconfig | 142 +++++++++++++++++++++++++++++++++++++
scripts/gcc-plugins/Makefile | 5 --
scripts/gcc-plugins/gcc-common.h | 26 ++++---
5 files changed, 184 insertions(+), 172 deletions(-)
create mode 100644 scripts/gcc-plugins/Kconfig
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] gcc-plugin updates for v4.19-rc1
@ 2018-08-15 19:45 86% ` Kees Cook
0 siblings, 1 reply; 200+ results
From: Kees Cook @ 2018-08-15 19:45 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, Alexander Popov, Dave Hansen,
Ingo Molnar, Masahiro Yamada, Thomas Gleixner, Tycho Andersen,
Mark Rutland, Laura Abbott, Will Deacon
On Wed, Aug 15, 2018 at 12:04 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Wed, Aug 15, 2018 at 11:35 AM Kees Cook <keescook@chromium.org> wrote:
>>
>> I swear I'm doing my best. Are you speaking of
>> stackleak_check_alloca() or stackleak_erase()? These were both
>> discussed on the list, and we weren't able to come up with
>> alternatives: in both cases we're off the stack, and recovery is
>> seemingly impossible.
>
> Why do you even *test* that thing? Why don't you just allocate stack
> and clear it.
I feel like we're talking cross purposes. The BUG() cases were for
places where we detect that we're executing with an impossible stack
pointer. It seems like trying to recover from that would just hide the
corruption for a later time that would be much harder to debug. These
weren't left in here to upset you. :) I have tried to take your "make
it debuggable" declaration to heart.
> Dammit, the whole f*cking point of this patch-set is to clear the
> stack used. It is *not* supposed to do anything else. If the process
> runs out of stack, that's caught by the vmalloc'ed stack.
It also handles VLA abuse, since those could (and have in past
exploits) been used to jump over guard pages. If you're saying you
want to see VLAs entirely removed and this feature dropped from the
plugin before you'll accept it, that's what we can do. I was trying to
help things develop in parallel since we're now three releases into
removing VLAs and it continues to be slow work.
> And if you don't have vmalloc'ed stack, then clearly you don't care.
Agreed: this is why the plugin already does an "imply VMAP_STACK" for
Kconfig. Are you suggesting we should make it a hard "depends on
VMAP_STACK"?
> I refuse to take this kind of code that does stupid things, and then
> *because* it does those initial stupid things it does even more stupid
> things to correct for it.
>
> I hated the thing to begin with, told people that there are better
> approaches that don't have the downsides, got ignored, and then I'm
> pushed crap.
I tried to detail in the pull request how we absolutely did not ignore
you. Something like 15 people have been helping to remove VLAs, and
I've been testing both gcc's stack forced-initialization patch and
Clang's, and doing it via a plugin (none are really "there" yet).
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 86%]
* Re: [GIT PULL] gcc-plugin updates for v4.19-rc1
@ 2018-08-15 20:56 87% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-08-15 20:56 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, Alexander Popov, Dave Hansen,
Ingo Molnar, Masahiro Yamada, Thomas Gleixner, Tycho Andersen,
Mark Rutland, Laura Abbott, Will Deacon, Herbert Xu,
linux-crypto
On Wed, Aug 15, 2018 at 1:18 PM, Linus Torvalds
<torvalds@linux-foundation.org> 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 thought VLA's were mostly gone.
Yes. Out of the ~115 instances we counted when we started with v4.16,
we've chipped away at them pretty steadily. Right now there are two
"one-off"s that haven't been picked up by maintainers:
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://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=vla/crypto
And after that, there's a single patch to move -Wvla up into the
top-level Makefile:
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 [relevance 87%]
* [GIT PULL] VLA removal leftovers for v4.19-rc1
@ 2018-08-16 23:54 91% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-08-16 23:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Arnd Bergmann, Shawn Guo
Hi Linus,
Please pull these two VLA removals for v4.19-rc1. It didn't seem
sensible to me to wait to add these: they're both trivial and have been
sitting in -next while I tried to get them picked up by their respective
maintainers. Instead, I can just be that maintainer. :) After these,
only some core crypto VLA removals remain, as the series that fixes them
is still under review.
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 tags/vla-leftovers-v4.19-rc1
for you to fetch changes up to d8dfa59f5a512a536b80a4a8f12fa993683f48df:
bus: imx-weim: Remove VLA usage (2018-08-13 13:40:52 -0700)
----------------------------------------------------------------
VLA leftovers pull summary:
- bus/imx-weim: Use maximum register count to avoid VLA
- drm/i2c/tda9950: Use maximum CEC message size to avoid VLA
----------------------------------------------------------------
Kees Cook (2):
drm/i2c: tda9950: Remove VLA usage
bus: imx-weim: Remove VLA usage
drivers/bus/imx-weim.c | 7 ++++++-
drivers/gpu/drm/i2c/tda9950.c | 5 ++++-
2 files changed, 10 insertions(+), 2 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 91%]
* [GIT PULL] stackleak plugin for v4.19-rc1 (take 2)
@ 2018-08-21 18:06 72% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-08-21 18:06 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Alexander Popov, Dave Hansen, Ingo Molnar,
Laura Abbott, Thomas Gleixner, Tycho Andersen
Hi Linus,
Please pull this corrected stackleak plugin for v4.19-rc1. The appropriate
Monty Python quote for this could be: "pull the other one"[1]. :)
This version has all the alloca() detection/checking code removed (which
removes both the x86 and arm64 BUG() usage) since we have almost finished
eradicating VLAs from the kernel. Additionally, the stack_erase() BUG()
has been removed by shifting the test to an earlier and recoverable
location.
The earlier plugin has been in -next for about two development cycles,
and this reduced version has had a further 5 days.
Notes edited down from the first pull request: this is the STACKLEAK
plugin ported by Alexander Popov. It provides efficient stack content
poisoning at syscall exit. This creates a defense against at least two
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)
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 have already been merged through the arm64 tree
(written by Laura Abbott and reviewed by Mark Rutland and Will Deacon).
Thanks!
-Kees
[1] https://www.youtube.com/watch?v=JHFXG3r_0B8#t=27
The following changes since commit 5c60a7389d795e001c8748b458eb76e3a5b6008c:
Merge tag 'for-linus-4.19-ofs1' of git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux (2018-08-16 10:53:45 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/stackleak-plugin-v4.19-rc1
for you to fetch changes up to de75c4d4bdfc84b07c597239edd3f26117a841e8:
arm64: Drop unneeded stackleak_check_alloca() (2018-08-21 10:40:52 -0700)
----------------------------------------------------------------
Stackleak GCC plugin:
- Stackleak GCC plugin, x86 support, test, docs, knob (Alexander Popov)
----------------------------------------------------------------
Alexander Popov (7):
x86/entry: Add STACKLEAK erasing the kernel stack at the end of syscalls
gcc-plugins: Add STACKLEAK plugin for tracking the kernel stack
lkdtm: Add a test for STACKLEAK
fs/proc: Show STACKLEAK metrics in the /proc file system
doc: self-protection: Add information about STACKLEAK feature
stackleak: Allow runtime disabling of kernel stack erasing
arm64: Drop unneeded stackleak_check_alloca()
Documentation/security/self-protection.rst | 10 +-
Documentation/sysctl/kernel.txt | 18 ++
Documentation/x86/x86_64/mm.txt | 2 +
arch/Kconfig | 7 +
arch/arm64/kernel/process.c | 22 --
arch/x86/Kconfig | 1 +
arch/x86/entry/calling.h | 14 +
arch/x86/entry/entry_32.S | 7 +
arch/x86/entry/entry_64.S | 3 +
arch/x86/entry/entry_64_compat.S | 5 +
drivers/misc/lkdtm/Makefile | 2 +
drivers/misc/lkdtm/core.c | 1 +
drivers/misc/lkdtm/lkdtm.h | 3 +
drivers/misc/lkdtm/stackleak.c | 73 +++++
fs/proc/base.c | 18 ++
include/linux/sched.h | 5 +
include/linux/stackleak.h | 35 +++
kernel/Makefile | 4 +
kernel/fork.c | 3 +
kernel/stackleak.c | 132 +++++++++
kernel/sysctl.c | 15 +-
scripts/Makefile.gcc-plugins | 10 +
scripts/gcc-plugins/Kconfig | 51 ++++
scripts/gcc-plugins/stackleak_plugin.c | 427 +++++++++++++++++++++++++++++
24 files changed, 840 insertions(+), 28 deletions(-)
create mode 100644 drivers/misc/lkdtm/stackleak.c
create mode 100644 include/linux/stackleak.h
create mode 100644 kernel/stackleak.c
create mode 100644 scripts/gcc-plugins/stackleak_plugin.c
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 72%]
* [GIT PULL] gcc-plugins update for v4.19-rc1 (fix)
@ 2018-08-23 17:28 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-08-23 17:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Masahiro Yamada, Stefan Agner
Hi,
Please pull this gcc-plugins fix for v4.19-rc1. This is for better
behavior when the kernel is built with Clang, reported by Stefan Agner.
Thanks!
-Kees
The following changes since commit 7ccb95e8fe9131b8fa14b947c60dfb30044fa002:
gcc-plugins: Regularize Makefile.gcc-plugins (2018-07-24 16:11:07 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/gcc-plugins-v4.19-rc1-fix
for you to fetch changes up to b04413330c773c808c4c6a6cdd278f8ee0f8b613:
gcc-plugins: Disable when building under Clang (2018-08-23 10:06:12 -0700)
----------------------------------------------------------------
gcc plugin fix:
- Lift gcc test into Kconfig
----------------------------------------------------------------
Kees Cook (1):
gcc-plugins: Disable when building under Clang
scripts/gcc-plugins/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] s390 patches for the 4.19 merge window #2
@ 2018-09-05 0:16 92% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-09-05 0:16 UTC (permalink / raw)
To: Harald Freudenberger
Cc: Martin Schwidefsky, linux-kernel, linux-s390, Heiko Carstens
On Fri, Aug 24, 2018 at 12:42 AM, Martin Schwidefsky
<schwidefsky@de.ibm.com> wrote:
> Harald Freudenberger (5):
> s390/zcrypt: hex string mask improvements for apmask and aqmask.
This (and an earlier 2017 commit) adds VLAs, which are being
removed[1] from the kernel:
drivers/s390/crypto/ap_bus.c:980:3: warning: ISO C90 forbids variable
length array ‘clrm’ [-Wvla]
drivers/s390/crypto/ap_bus.c:981:3: warning: ISO C90 forbids variable
length array ‘setm’ [-Wvla]
drivers/s390/crypto/ap_bus.c:995:3: warning: ISO C90 forbids variable
length array ‘setm’ [-Wvla]
static int process_mask_arg(const char *str,
unsigned long *bitmap, int bits,
struct mutex *lock)
...
DECLARE_BITMAP(clrm, bits);
DECLARE_BITMAP(setm, bits);
Can someone please adjust this to make these fixed size again?
Thanks!
-Kees
[1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] pstore fixes for v4.19-rc4
@ 2018-09-13 16:32 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-09-13 16:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Bin Yang
Hi Linus,
Please pull this pstore fix for v4.19-rc4. It fixes a 6 year old pstore
bug that everyone just got lucky in avoiding, likely due only using
page-aligned persistent ram regions.
Thanks!
-Kees
The following changes since commit 57361846b52bc686112da6ca5368d11210796804:
Linux 4.19-rc2 (2018-09-02 14:37:30 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/pstore-v4.19-rc4
for you to fetch changes up to 831b624df1b420c8f9281ed1307a8db23afb72df:
pstore: Fix incorrect persistent ram buffer mapping (2018-09-13 09:14:57 -0700)
----------------------------------------------------------------
pstore fixes for v4.19-rc4:
- Handle page-vs-byte offset handling between iomap and vmap (Bin Yang)
----------------------------------------------------------------
Bin Yang (1):
pstore: Fix incorrect persistent ram buffer mapping
fs/pstore/ram_core.c | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] pstore fix for v4.19-rc7
@ 2018-09-30 17:29 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-09-30 17:29 UTC (permalink / raw)
To: Greg KH
Cc: linux-kernel, Anton Vorontsov, Colin Cross, Geliang Tang,
Joel Fernandes, nixiaoming, Tony Luck
Hi Greg,
Please pull this pstore fix for v4.19-rc7.
Thanks!
-Kees
The following changes since commit 831b624df1b420c8f9281ed1307a8db23afb72df:
pstore: Fix incorrect persistent ram buffer mapping (2018-09-13 09:14:57 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/pstore-v4.19-rc7
for you to fetch changes up to bac6f6cda206ad7cbe0c73c35e494377ce9c4749:
pstore/ram: Fix failure-path memory leak in ramoops_init (2018-09-30 10:15:41 -0700)
----------------------------------------------------------------
Fixes for v4.19-rc7
- Fix failure-path memory leak in ramoops_init (nixiaoming)
----------------------------------------------------------------
Kees Cook (1):
pstore/ram: Fix failure-path memory leak in ramoops_init
fs/pstore/ram.c | 29 +++++++++++++++++++++++++----
1 file changed, 25 insertions(+), 4 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] allocator argument fixes for v4.19-rc8
@ 2018-10-11 16:52 90% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-10-11 16:52 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel
Hi Greg,
Please pull this fix for open-coded multiplication in allocator arguments
for v4.19-rc8. This has been in linux-next for almost a week with no
reported issues. As discussed last week[1] this catches 4.19 up to
the same level of coverage we had in 4.18 for avoiding these kinds of
unchecked multiplications.
Thanks!
-Kees
[1] https://lkml.kernel.org/r/CAGXu5jJfs0KpRa6yag=ud0sJVW-tM-E4xuvgCMnBdFfDck5E1g@mail.gmail.com
The following changes since commit 57361846b52bc686112da6ca5368d11210796804:
Linux 4.19-rc2 (2018-09-02 14:37:30 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/alloc-args-v4.19-rc8
for you to fetch changes up to 329e09893909d409039f6a79757d9b80b67efe39:
treewide: Replace more open-coded allocation size multiplications (2018-10-05 18:06:30 -0700)
----------------------------------------------------------------
Fix open-coded multiplication arguments to allocators
- Fixes several new open-coded multiplications added in the 4.19 merge window.
----------------------------------------------------------------
Kees Cook (1):
treewide: Replace more open-coded allocation size multiplications
drivers/bluetooth/hci_qca.c | 2 +-
drivers/crypto/inside-secure/safexcel.c | 8 +++++---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c | 4 ++--
drivers/hwmon/npcm750-pwm-fan.c | 2 +-
drivers/md/dm-integrity.c | 3 ++-
drivers/net/wireless/mediatek/mt76/usb.c | 10 +++++-----
drivers/pci/controller/pcie-cadence.c | 4 ++--
drivers/tty/serial/qcom_geni_serial.c | 4 ++--
net/sched/sch_cake.c | 2 +-
10 files changed, 22 insertions(+), 19 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 90%]
* [GIT PULL] loadpin updates for security-next
@ 2018-10-18 23:05 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-10-18 23:05 UTC (permalink / raw)
To: James Morris
Cc: linux-kernel, Casey Schaufler, John Johansen, linux-security-module
Hi James,
Please pull these loadpin changes for security-next. This is a small
reporting improvement and the param change needed for the ordering
series (but since the loadpin change is desired and separable, I'm
putting it here).
Thanks!
-Kees
The following changes since commit 57361846b52bc686112da6ca5368d11210796804:
Linux 4.19-rc2 (2018-09-02 14:37:30 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/loadpin-security-next
for you to fetch changes up to 13523bef1e2154b6d02836cd0f6c0ffc89b2eae6:
LoadPin: Rename boot param "enabled" to "enforce" (2018-10-18 15:29:44 -0700)
----------------------------------------------------------------
LoadPin: report improvement and parameter renaming
- Report human-readable device name during init
- Change boot parameter and Kconfig "enabled" to "enforce"
----------------------------------------------------------------
Kees Cook (2):
LoadPin: Report friendly block device name
LoadPin: Rename boot param "enabled" to "enforce"
security/loadpin/Kconfig | 4 ++--
security/loadpin/loadpin.c | 26 +++++++++++++++-----------
2 files changed, 17 insertions(+), 13 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] pstore updates for v4.20-rc1
@ 2018-10-22 14:24 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-10-22 14:24 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Guenter Roeck, Joel Fernandes, Sai Prakash Ranjan
Hi Linus,
Please pull these pstore changes for v4.20-rc1.
Thanks!
-Kees
The following changes since commit 57361846b52bc686112da6ca5368d11210796804:
Linux 4.19-rc2 (2018-09-02 14:37:30 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/pstore-v4.20-rc1
for you to fetch changes up to 1227daa43bce1318ff6fb54e6cd862b4f60245c7:
pstore/ram: Clarify resource reservation labels (2018-10-22 07:11:58 -0700)
----------------------------------------------------------------
pstore improvements:
- refactor init to happen as early as possible again (Joel Fernandes)
- improve resource reservation names
----------------------------------------------------------------
Joel Fernandes (Google) (1):
pstore: Allocate compression during late_initcall()
Kees Cook (3):
pstore: Centralize init/exit routines
pstore: Refactor compression initialization
pstore/ram: Clarify resource reservation labels
fs/pstore/inode.c | 11 ++-----
fs/pstore/internal.h | 5 ++--
fs/pstore/platform.c | 75 ++++++++++++++++++++++++++++++++++++++--------
fs/pstore/ram.c | 18 ++++++++---
fs/pstore/ram_core.c | 11 ++++---
include/linux/pstore_ram.h | 3 +-
6 files changed, 90 insertions(+), 33 deletions(-)
--
Kees Cook
Pixel Security
^ permalink raw reply [relevance 92%]
* [GIT PULL] gcc-plugin stackleak for v4.20-rc1
@ 2018-10-24 19:14 73% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-10-24 19:14 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Alexander Popov, Dave Hansen, Ingo Molnar,
Laura Abbott, Thomas Gleixner, Tycho Andersen
Hi Linus,
Please pull this new GCC plugin, stackleak, for v4.20-rc1. This plugin
was ported from grsecurity by Alexander Popov. It provides efficient
stack content poisoning at syscall exit. This creates a defense against
at least two classes of flaws:
- Uninitialized stack usage. (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.
The x86 hooks are included in this series (which have been reviewed by
Ingo, Dave Hansen, and Thomas Gleixner). The arm64 hooks have already
been merged through the arm64 tree (written by Laura Abbott and reviewed
by Mark Rutland and Will Deacon).
With VLAs being removed this release (the final "-Wvla" patch is waiting
for the crypto, powerpc, and block trees to land in the merge window),
there is no need for alloca() protection, so it has been removed from
the plugin.
There is no use of BUG() or panic() (in fact, since the alloca()
protection has been removed, the arm64 hook using them is removed
as well).
There are two merge conflicts:
drivers/misc/lkdtm/core.c: Trivial addition of a new test.
Documentation/x86/x86_64/mm.txt: Looks nasty, but is actually trivial.
The memory layout tables were rewritten, so the two additions of
"STACKLEAK_POISON value in this last hole: ffffffffffff4111" just
belong at the end of the newly reformatted tables.
Thanks!
-Kees
The following changes since commit 57361846b52bc686112da6ca5368d11210796804:
Linux 4.19-rc2 (2018-09-02 14:37:30 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/stackleak-v4.20-rc1
for you to fetch changes up to 6fcde90466738b84a073e4f4d18c50015ee29fb2:
arm64: Drop unneeded stackleak_check_alloca() (2018-09-04 10:35:48 -0700)
----------------------------------------------------------------
New gcc plugin: stackleak
- Introduces the stackleak gcc plugin ported from grsecurity by Alexander
Popov, with x86 and arm64 support.
----------------------------------------------------------------
Alexander Popov (7):
x86/entry: Add STACKLEAK erasing the kernel stack at the end of syscalls
gcc-plugins: Add STACKLEAK plugin for tracking the kernel stack
lkdtm: Add a test for STACKLEAK
fs/proc: Show STACKLEAK metrics in the /proc file system
doc: self-protection: Add information about STACKLEAK feature
stackleak: Allow runtime disabling of kernel stack erasing
arm64: Drop unneeded stackleak_check_alloca()
Documentation/security/self-protection.rst | 10 +-
Documentation/sysctl/kernel.txt | 18 ++
Documentation/x86/x86_64/mm.txt | 2 +
arch/Kconfig | 7 +
arch/arm64/kernel/process.c | 22 --
arch/x86/Kconfig | 1 +
arch/x86/entry/calling.h | 14 +
arch/x86/entry/entry_32.S | 7 +
arch/x86/entry/entry_64.S | 3 +
arch/x86/entry/entry_64_compat.S | 5 +
drivers/misc/lkdtm/Makefile | 2 +
drivers/misc/lkdtm/core.c | 1 +
drivers/misc/lkdtm/lkdtm.h | 3 +
drivers/misc/lkdtm/stackleak.c | 73 +++++
fs/proc/base.c | 18 ++
include/linux/sched.h | 5 +
include/linux/stackleak.h | 35 +++
kernel/Makefile | 4 +
kernel/fork.c | 3 +
kernel/stackleak.c | 132 +++++++++
kernel/sysctl.c | 15 +-
scripts/Makefile.gcc-plugins | 10 +
scripts/gcc-plugins/Kconfig | 51 ++++
scripts/gcc-plugins/stackleak_plugin.c | 427 +++++++++++++++++++++++++++++
24 files changed, 840 insertions(+), 28 deletions(-)
create mode 100644 drivers/misc/lkdtm/stackleak.c
create mode 100644 include/linux/stackleak.h
create mode 100644 kernel/stackleak.c
create mode 100644 scripts/gcc-plugins/stackleak_plugin.c
--
Kees Cook
^ permalink raw reply [relevance 73%]
* Re: Git pull ack emails..
@ 2018-10-24 22:21 84% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-10-24 22:21 UTC (permalink / raw)
To: Linus Torvalds
Cc: Boris Brezillon, Catalin Marinas, Christoph Hellwig,
Guenter Roeck, Jacek Anaszewski, Jens Axboe, Linus Walleij,
Mark Brown, Ulf Hansson, Greg KH, Linux Kernel Mailing List
On Tue, Oct 23, 2018 at 1:41 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> So I've got a few options:
>
> - just don't do it
As with other folks, this is what we're used to, but it does cause a
lot of "polling" your tree to see what's landed. (And your "Pulled"
email to pstore today scared the crap out of me briefly -- it made me
go look for this thread...)
I enjoyed getting Greg's "Pulled" emails for post-rc4, since it closes
the loop. I've always hugely preferred getting "Applied" etc emails,
and I try to make sure I always send them too.
> - acking the pull request before it's validated and finalized.
While this can work, I would find it personally only a little useful
since it doesn't actually contain the information I (and any folks
contributing to the pulled patches) need: has it landed? When I send a
pull request for security hardening things, I'm mentally wearing my
seasoned asbestos suit until I see the PR has landed. (Other trees of
mine like pstore don't tend to trigger rants, so those are likely just
fine for this notification method.)
> - starting the reply when doing the pull, leaving the email open in a
> separate window, going on to the next pull request, and then when
> build tests are done and I'll start the next one, finish off the old
> pending email.
This sounds like an annoying fragmentation of your workflow. I thought
Mark and Kirill's suggestion to stash the PR Message-Id in your merge
commit would be pretty easy to automate, though. (And may just be a
good bit of record-keeping anyway...)
On the balance, I think since most things you start to pull are, in
fact, pulled, the "send at start" method covers most cases and does
let people know when you've gotten to their PR. And I can spend less
time wearing my preparatory asbestos -- just from "Pulled" email until
I see it land. ;)
--
Kees Cook
^ permalink raw reply [relevance 84%]
* [GIT PULL] VLA removal for v4.20-rc1
@ 2018-10-28 17:24 89% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-10-28 17:24 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Andrew Morton, David Airlie, dri-devel, intel-gfx,
linux-kbuild, Masahiro Yamada, Nick Desaulniers
Hi Linus,
Please pull these VLA removal changes for v4.20-rc1. This turns on "-Wvla"
globally now that the last few trees with their VLA removals have landed
(crypto, block, net, and powerpc). Arnd mentioned that there may be a
couple more VLAs hiding in hard-to-find randconfigs, but nothing big has
shaken out in the last month or so in linux-next. We should be basically
VLA-free now! Wheee. :)
Thanks!
-Kees
The following changes since commit 57361846b52bc686112da6ca5368d11210796804:
Linux 4.19-rc2 (2018-09-02 14:37:30 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/vla-v4.20-rc1
for you to fetch changes up to 0bb95f80a38f82884693194ea720e9cca5e12ada:
Makefile: Globally enable VLA warning (2018-10-11 08:17:50 -0700)
----------------------------------------------------------------
Globally warn on VLA use
- Remove unused fallback for BUILD_BUG_ON (which technically contains a VLA)
- Lift -Wvla to the top-level Makefile
----------------------------------------------------------------
Kees Cook (1):
Makefile: Globally enable VLA warning
Masahiro Yamada (1):
compiler.h: give up __compiletime_assert_fallback()
Makefile | 3 +++
drivers/gpu/drm/i915/Makefile | 2 +-
include/linux/compiler.h | 17 +----------------
lib/Makefile | 2 ++
scripts/Makefile.extrawarn | 1 -
5 files changed, 7 insertions(+), 18 deletions(-)
--
Kees Cook
^ permalink raw reply [relevance 89%]
* [GIT PULL] pstore fix for v4.20-rc5
@ 2018-11-29 23:15 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-11-29 23:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Joel Fernandes, Kees Cook
Hi Linus,
Please pull this pstore fix for v4.20-rc5.
Thanks!
-Kees
The following changes since commit 1227daa43bce1318ff6fb54e6cd862b4f60245c7:
pstore/ram: Clarify resource reservation labels (2018-10-22 07:11:58 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/pstore-v4.20-rc5
for you to fetch changes up to 89d328f637b9904b6d4c9af73c8a608b8dd4d6f8:
pstore/ram: Correctly calculate usable PRZ bytes (2018-11-29 13:46:43 -0800)
----------------------------------------------------------------
pstore fix:
- Fix corrupted compression due to unlucky size choice with ECC
----------------------------------------------------------------
Kees Cook (1):
pstore/ram: Correctly calculate usable PRZ bytes
fs/pstore/ram.c | 15 ++++++---------
include/linux/pstore.h | 5 ++++-
2 files changed, 10 insertions(+), 10 deletions(-)
--
Kees Cook
^ permalink raw reply [relevance 92%]
* [GIT PULL] gcc-plugins fix for v4.20-rc5
@ 2018-11-30 17:18 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-11-30 17:18 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Alexander Popov, Masami Hiramatsu, Steven Rostedt
Hi Linus,
Please pull this gcc-plugin fix for v4.20-rc5.
Thanks!
-Kees
The following changes since commit ccda4af0f4b92f7b4c308d3acc262f4a7e3affad:
Linux 4.20-rc2 (2018-11-11 17:12:31 -0600)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/gcc-plugins-v4.20-rc5
for you to fetch changes up to ef1a8409348966f0b25ff97a170d6d0367710ea9:
stackleak: Disable function tracing and kprobes for stackleak_erase() (2018-11-30 09:05:07 -0800)
----------------------------------------------------------------
stackleak plugin fix
- Fix crash by not allowing kprobing of stackleak_erase() (Alexander Popov)
----------------------------------------------------------------
Alexander Popov (1):
stackleak: Disable function tracing and kprobes for stackleak_erase()
kernel/stackleak.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--
Kees Cook
^ permalink raw reply [relevance 92%]
* [GIT PULL] gcc-plugin updates for v4.20-rc6
@ 2018-12-07 17:08 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-12-07 17:08 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Alexander Popov, Anders Roxell, Arnd Bergmann,
Steven Rostedt
Hi Linus,
Please pull these gcc-plugin fixes for v4.20-rc6.
Thanks!
-Kees
The following changes since commit ef1a8409348966f0b25ff97a170d6d0367710ea9:
stackleak: Disable function tracing and kprobes for stackleak_erase() (2018-11-30 09:05:07 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/gcc-plugins-v4.20-rc6
for you to fetch changes up to 8fb2dfb228df785bbeb4d055a74402ef4b07fc25:
stackleak: Register the 'stackleak_cleanup' pass before the '*free_cfg' pass (2018-12-06 09:10:23 -0800)
----------------------------------------------------------------
Fixes for stackleak
- Remove tracing for inserted stack depth marking function (Anders Roxell)
- Move gcc-plugin pass location to avoid objtool warnings (Alexander Popov)
----------------------------------------------------------------
Alexander Popov (1):
stackleak: Register the 'stackleak_cleanup' pass before the '*free_cfg' pass
Anders Roxell (1):
stackleak: Mark stackleak_track_stack() as notrace
kernel/stackleak.c | 2 +-
scripts/gcc-plugins/stackleak_plugin.c | 8 +++++---
2 files changed, 6 insertions(+), 4 deletions(-)
--
Kees Cook
^ permalink raw reply [relevance 92%]
* [GIT PULL] seccomp updates for next
@ 2018-12-12 23:16 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-12-12 23:16 UTC (permalink / raw)
To: James Morris; +Cc: linux-kernel, Kees Cook, Serge Hallyn, Tycho Andersen
Hi James,
Please pull these seccomp changes for next.
Thanks!
-Kees
The following changes since commit ccda4af0f4b92f7b4c308d3acc262f4a7e3affad:
Linux 4.20-rc2 (2018-11-11 17:12:31 -0600)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-next
for you to fetch changes up to fec7b6690541b8128663a13c9586b1daf42b0a6c:
samples: add an example of seccomp user trap (2018-12-11 16:32:11 -0800)
----------------------------------------------------------------
Add SECCOMP_RET_USER_NOTIF
----------------------------------------------------------------
Tycho Andersen (4):
seccomp: hoist struct seccomp_data recalculation higher
seccomp: switch system call argument type to void *
seccomp: add a return code to trap to userspace
samples: add an example of seccomp user trap
Documentation/ioctl/ioctl-number.txt | 1 +
Documentation/userspace-api/seccomp_filter.rst | 84 +++++
include/linux/seccomp.h | 9 +-
include/linux/syscalls.h | 2 +-
include/uapi/linux/seccomp.h | 40 ++-
kernel/seccomp.c | 468 ++++++++++++++++++++++++-
samples/seccomp/.gitignore | 1 +
samples/seccomp/Makefile | 7 +-
samples/seccomp/user-trap.c | 375 ++++++++++++++++++++
tools/testing/selftests/seccomp/seccomp_bpf.c | 447 ++++++++++++++++++++++-
10 files changed, 1411 insertions(+), 23 deletions(-)
create mode 100644 samples/seccomp/user-trap.c
--
Kees Cook
^ permalink raw reply [relevance 92%]
* [GIT PULL] seccomp updates for next (part2)
@ 2018-12-14 16:25 92% Kees Cook
2018-12-17 18:00 92% ` Kees Cook
0 siblings, 1 reply; 200+ results
From: Kees Cook @ 2018-12-14 16:25 UTC (permalink / raw)
To: James Morris; +Cc: linux-kernel, Tycho Andersen
Hi James,
Please pull these seccomp fixes for -next.
Thanks!
-Kees
The following changes since commit fec7b6690541b8128663a13c9586b1daf42b0a6c:
samples: add an example of seccomp user trap (2018-12-11 16:32:11 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-next-part2
for you to fetch changes up to 4fc96ee9085d39ceeaa7b60cd475d0a474e7062f:
seccomp, s390: fix build for syscall type change (2018-12-13 16:51:01 -0800)
----------------------------------------------------------------
seccomp fixes for sparse warnings and s390 build (Tycho)
----------------------------------------------------------------
Tycho Andersen (2):
seccomp: fix poor type promotion
seccomp, s390: fix build for syscall type change
arch/s390/kernel/compat_wrapper.c | 2 +-
kernel/seccomp.c | 3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
--
Kees Cook
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] seccomp updates for next (part2)
2018-12-14 16:25 92% [GIT PULL] seccomp updates for next (part2) Kees Cook
@ 2018-12-17 18:00 92% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-12-17 18:00 UTC (permalink / raw)
To: James Morris; +Cc: LKML, Tycho Andersen, Heiko Carstens
On Fri, Dec 14, 2018 at 8:26 AM Kees Cook <keescook@chromium.org> wrote:
>
>
> Hi James,
>
> Please pull these seccomp fixes for -next.
>
> Thanks!
Friendly ping: James, can you pick this up for -next?
-Kees
>
> -Kees
>
> The following changes since commit fec7b6690541b8128663a13c9586b1daf42b0a6c:
>
> samples: add an example of seccomp user trap (2018-12-11 16:32:11 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-next-part2
>
> for you to fetch changes up to 4fc96ee9085d39ceeaa7b60cd475d0a474e7062f:
>
> seccomp, s390: fix build for syscall type change (2018-12-13 16:51:01 -0800)
>
> ----------------------------------------------------------------
> seccomp fixes for sparse warnings and s390 build (Tycho)
>
> ----------------------------------------------------------------
> Tycho Andersen (2):
> seccomp: fix poor type promotion
> seccomp, s390: fix build for syscall type change
>
> arch/s390/kernel/compat_wrapper.c | 2 +-
> kernel/seccomp.c | 3 +--
> 2 files changed, 2 insertions(+), 3 deletions(-)
>
> --
> Kees Cook
--
Kees Cook
^ permalink raw reply [relevance 92%]
* [GIT PULL] pstore updates for v4.21-rc1
@ 2018-12-17 23:50 85% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-12-17 23:50 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Dan Carpenter, Joel Fernandes (Google),
Peng Wang, Sebastian Andrzej Siewior, Thomas Meyer
Hi Linus,
Please pull these pstore changes for v4.21-rc1.
Thanks!
-Kees
The following changes since commit ccda4af0f4b92f7b4c308d3acc262f4a7e3affad:
Linux 4.20-rc2 (2018-11-11 17:12:31 -0600)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/pstore-v4.21-rc1
for you to fetch changes up to 8665569e97dd52920713b95675409648986b5b0d:
pstore/ram: Avoid NULL deref in ftrace merging failure path (2018-12-03 17:11:02 -0800)
----------------------------------------------------------------
pstore improvements and refactorings
- Improve compression handling
- Refactor argument handling during initialization
- Avoid needless locking for saner EFI backend handling
- Add more kern-doc and improve debugging output
----------------------------------------------------------------
Joel Fernandes (Google) (3):
pstore: Map PSTORE_TYPE_* to strings
pstore/ram: Simplify ramoops_get_next_prz() arguments
pstore/ram: Do not treat empty buffers as valid
Kees Cook (11):
pstore/ram: Correctly calculate usable PRZ bytes
Merge branch 'for-linus/pstore' into for-next/pstore
pstore: Do not use crash buffer for decompression
pstore: Remove needless lock during console writes
pstore/ram: Standardize module name in ramoops
pstore/ram: Report backend assignments with finer granularity
pstore/ram: Add kern-doc for struct persistent_ram_zone
pstore: Improve and update some comments and status output
pstore: Replace open-coded << with BIT()
pstore: Convert buf_lock to semaphore
pstore/ram: Avoid NULL deref in ftrace merging failure path
Peng Wang (1):
pstore: Avoid duplicate call of persistent_ram_zap()
Thomas Meyer (1):
pstore: Fix bool initialization/comparison
arch/powerpc/kernel/nvram_64.c | 2 -
drivers/acpi/apei/erst.c | 3 +-
drivers/firmware/efi/efi-pstore.c | 4 +-
fs/pstore/ftrace.c | 2 +-
fs/pstore/inode.c | 51 +----------
fs/pstore/platform.c | 173 +++++++++++++++++++++-----------------
fs/pstore/ram.c | 78 +++++++----------
fs/pstore/ram_core.c | 45 ++++++++--
include/linux/pstore.h | 39 ++++++---
include/linux/pstore_ram.h | 50 ++++++++++-
10 files changed, 241 insertions(+), 206 deletions(-)
--
Kees Cook
^ permalink raw reply [relevance 85%]
* [GIT PULL] gcc-plugins update for v4.21-rc1
@ 2018-12-18 0:01 90% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2018-12-18 0:01 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Ard Biesheuvel, Arnd Bergmann, Emese Revfy,
Laura Abbott, Nicolas Pitre, Russell King
Hi Linus,
Please pull this gcc-plugin addition for v4.21-rc1. Both arm and arm64 are
gaining per-task stack canaries (to match x86), but arm is being done with
a gcc plugin, hence it going through the gcc-plugins tree.
Thanks!
-Kees
The following changes since commit ccda4af0f4b92f7b4c308d3acc262f4a7e3affad:
Linux 4.20-rc2 (2018-11-11 17:12:31 -0600)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/gcc-plugins-v4.21-rc1
for you to fetch changes up to 189af4657186da08a2e79fb8e906cfd82b2ccddc:
ARM: smp: add support for per-task stack canaries (2018-12-12 13:20:07 -0800)
----------------------------------------------------------------
New gcc-plugin:
- Enable per-task stack protector for ARM (Ard Biesheuvel)
----------------------------------------------------------------
Ard Biesheuvel (1):
ARM: smp: add support for per-task stack canaries
arch/arm/Kconfig | 15 ++++
arch/arm/Makefile | 12 +++
arch/arm/boot/compressed/Makefile | 1 +
arch/arm/include/asm/stackprotector.h | 12 ++-
arch/arm/include/asm/thread_info.h | 3 +
arch/arm/kernel/asm-offsets.c | 4 +
arch/arm/kernel/process.c | 6 +-
scripts/Makefile.gcc-plugins | 6 ++
scripts/gcc-plugins/Kconfig | 4 +
scripts/gcc-plugins/arm_ssp_per_task_plugin.c | 103 ++++++++++++++++++++++++++
10 files changed, 163 insertions(+), 3 deletions(-)
create mode 100644 scripts/gcc-plugins/arm_ssp_per_task_plugin.c
--
Kees Cook
^ permalink raw reply [relevance 90%]
* Re: [GIT PULL] security: seccomp changes for v4.21
@ 2019-01-07 21:09 92% ` Kees Cook
0 siblings, 1 reply; 200+ results
From: Kees Cook @ 2019-01-07 21:09 UTC (permalink / raw)
To: Ingo Molnar, Tycho Andersen
Cc: James Morris, Linus Torvalds, LKML, linux-security-module,
Thomas Gleixner, Borislav Petkov
On Mon, Jan 7, 2019 at 2:15 AM Ingo Molnar <mingo@kernel.org> wrote:
>
>
> * James Morris <jmorris@namei.org> wrote:
>
> > From Kees:
> >
> > "- Add SECCOMP_RET_USER_NOTIF
> >
> > - seccomp fixes for sparse warnings and s390 build (Tycho)"
> >
> >
> >
> > The following changes since commit 1072bd678547f8663cfb81a22fdb50c589e4976e:
> >
> > security: fs: make inode explicitly non-modular (2018-12-12 14:58:51 -0800)
> >
> > are available in the Git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-seccomp
> >
> > for you to fetch changes up to 55b8cbe470d103b44104c64dbf89e5cad525d4e0:
> >
> > Merge tag 'seccomp-next-part2' of https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux into next-seccomp (2018-12-17 11:36:26 -0800)
> >
> > ----------------------------------------------------------------
> > James Morris (2):
> > Merge tag 'seccomp-next' of https://git.kernel.org/.../kees/linux into next-seccomp
> > Merge tag 'seccomp-next-part2' of https://git.kernel.org/.../kees/linux into next-seccomp
> >
> > Tycho Andersen (6):
> > seccomp: hoist struct seccomp_data recalculation higher
> > seccomp: switch system call argument type to void *
> > seccomp: add a return code to trap to userspace
> > samples: add an example of seccomp user trap
> > seccomp: fix poor type promotion
> > seccomp, s390: fix build for syscall type change
> >
> > Documentation/ioctl/ioctl-number.txt | 1 +
> > Documentation/userspace-api/seccomp_filter.rst | 84 +++++
> > arch/s390/kernel/compat_wrapper.c | 2 +-
> > include/linux/seccomp.h | 9 +-
> > include/linux/syscalls.h | 2 +-
> > include/uapi/linux/seccomp.h | 40 ++-
> > kernel/seccomp.c | 467 ++++++++++++++++++++++++-
> > samples/seccomp/.gitignore | 1 +
> > samples/seccomp/Makefile | 7 +-
> > samples/seccomp/user-trap.c | 375 ++++++++++++++++++++
> > tools/testing/selftests/seccomp/seccomp_bpf.c | 447 ++++++++++++++++++++++-
> > 11 files changed, 1411 insertions(+), 24 deletions(-)
> > create mode 100644 samples/seccomp/user-trap.c
>
> 32-bit x86 allyesconfig doesn't build:
>
> /usr/bin/ld: i386:x86-64 architecture of input file `samples/seccomp/user-trap.o' is incompatible with i386 output
> /usr/bin/ld: samples/seccomp/user-trap.o: file class ELFCLASS64 incompatible with ELFCLASS32
> /usr/bin/ld: final link failed: File in wrong format
> collect2: error: ld returned 1 exit status
> scripts/Makefile.host:99: recipe for target 'samples/seccomp/user-trap' failed
> make[2]: *** [samples/seccomp/user-trap] Error 1
>
> Is this a known regression?
That looks like something is busted in the samples Makefile? Tycho,
are you able to reproduce this?
-Kees
--
Kees Cook
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] security: seccomp changes for v4.21
@ 2019-01-07 22:04 92% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2019-01-07 22:04 UTC (permalink / raw)
To: Tycho Andersen
Cc: Ingo Molnar, James Morris, Linus Torvalds, LKML,
linux-security-module, Thomas Gleixner, Borislav Petkov
On Mon, Jan 7, 2019 at 1:53 PM Tycho Andersen <tycho@tycho.ws> wrote:
>
> Hi,
>
> On Mon, Jan 07, 2019 at 01:09:09PM -0800, Kees Cook wrote:
> > On Mon, Jan 7, 2019 at 2:15 AM Ingo Molnar <mingo@kernel.org> wrote:
> > >
> > >
> > > * James Morris <jmorris@namei.org> wrote:
> > >
> > > > From Kees:
> > > >
> > > > "- Add SECCOMP_RET_USER_NOTIF
> > > >
> > > > - seccomp fixes for sparse warnings and s390 build (Tycho)"
> > > >
> > > >
> > > >
> > > > The following changes since commit 1072bd678547f8663cfb81a22fdb50c589e4976e:
> > > >
> > > > security: fs: make inode explicitly non-modular (2018-12-12 14:58:51 -0800)
> > > >
> > > > are available in the Git repository at:
> > > >
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-seccomp
> > > >
> > > > for you to fetch changes up to 55b8cbe470d103b44104c64dbf89e5cad525d4e0:
> > > >
> > > > Merge tag 'seccomp-next-part2' of https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux into next-seccomp (2018-12-17 11:36:26 -0800)
> > > >
> > > > ----------------------------------------------------------------
> > > > James Morris (2):
> > > > Merge tag 'seccomp-next' of https://git.kernel.org/.../kees/linux into next-seccomp
> > > > Merge tag 'seccomp-next-part2' of https://git.kernel.org/.../kees/linux into next-seccomp
> > > >
> > > > Tycho Andersen (6):
> > > > seccomp: hoist struct seccomp_data recalculation higher
> > > > seccomp: switch system call argument type to void *
> > > > seccomp: add a return code to trap to userspace
> > > > samples: add an example of seccomp user trap
> > > > seccomp: fix poor type promotion
> > > > seccomp, s390: fix build for syscall type change
> > > >
> > > > Documentation/ioctl/ioctl-number.txt | 1 +
> > > > Documentation/userspace-api/seccomp_filter.rst | 84 +++++
> > > > arch/s390/kernel/compat_wrapper.c | 2 +-
> > > > include/linux/seccomp.h | 9 +-
> > > > include/linux/syscalls.h | 2 +-
> > > > include/uapi/linux/seccomp.h | 40 ++-
> > > > kernel/seccomp.c | 467 ++++++++++++++++++++++++-
> > > > samples/seccomp/.gitignore | 1 +
> > > > samples/seccomp/Makefile | 7 +-
> > > > samples/seccomp/user-trap.c | 375 ++++++++++++++++++++
> > > > tools/testing/selftests/seccomp/seccomp_bpf.c | 447 ++++++++++++++++++++++-
> > > > 11 files changed, 1411 insertions(+), 24 deletions(-)
> > > > create mode 100644 samples/seccomp/user-trap.c
> > >
> > > 32-bit x86 allyesconfig doesn't build:
> > >
> > > /usr/bin/ld: i386:x86-64 architecture of input file `samples/seccomp/user-trap.o' is incompatible with i386 output
> > > /usr/bin/ld: samples/seccomp/user-trap.o: file class ELFCLASS64 incompatible with ELFCLASS32
> > > /usr/bin/ld: final link failed: File in wrong format
> > > collect2: error: ld returned 1 exit status
> > > scripts/Makefile.host:99: recipe for target 'samples/seccomp/user-trap' failed
> > > make[2]: *** [samples/seccomp/user-trap] Error 1
> > >
> > > Is this a known regression?
> >
> > That looks like something is busted in the samples Makefile? Tycho,
> > are you able to reproduce this?
>
> Given that the samples build only happens when CROSS_COMPILE is not
> set, I'll see about digging up a 32-bit box. But I think the patch
> below should fix it, I'll send it out when I actually get it tested.
Cool, thanks for looking at it! :)
>
> Sorry for the breakage!
>
> Tycho
>
>
> From b53b390ab554ef6e5b995ac050718fd62ed0803e Mon Sep 17 00:00:00 2001
> From: Tycho Andersen <tycho@tycho.ws>
> Date: Mon, 7 Jan 2019 14:46:34 -0700
> Subject: [PATCH] samples/seccomp: fix 32-bit build
>
> Both the .o and the actual executable need to be built with -m32 in order
> to link correctly.
>
> Signed-off-by: Tycho Andersen <tycho@tycho.ws>
And just for tracking:
Fixes: fec7b6690541 ("samples: add an example of seccomp user trap")
Thanks!
-Kees
> Reported-by: Ingo Molnar <mingo@kernel.org>
> ---
> samples/seccomp/Makefile | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/samples/seccomp/Makefile b/samples/seccomp/Makefile
> index 4920903c8009..a5607668a5c7 100644
> --- a/samples/seccomp/Makefile
> +++ b/samples/seccomp/Makefile
> @@ -37,6 +37,7 @@ HOSTCFLAGS_bpf-fancy.o += $(MFLAG)
> HOSTLDLIBS_bpf-direct += $(MFLAG)
> HOSTLDLIBS_bpf-fancy += $(MFLAG)
> HOSTLDLIBS_dropper += $(MFLAG)
> +HOSTLDLIBS_user-trap.o += $(MFLAG)
> HOSTLDLIBS_user-trap += $(MFLAG)
> endif
> always := $(hostprogs-m)
> --
> 2.19.1
>
--
Kees Cook
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] seccomp: build fix for v5.0-rc2
@ 2019-01-08 21:11 92% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2019-01-08 21:11 UTC (permalink / raw)
To: James Morris; +Cc: Linus Torvalds, linux-security-module, Ingo Molnar, LKML
This was already picked up by x86-urgent...
-Kees
On Tue, Jan 8, 2019 at 1:04 PM James Morris <jmorris@namei.org> wrote:
>
> Please pull this fix for a build regression in seccomp.
>
> The following changes since commit 7b55851367136b1efd84d98fea81ba57a98304cf:
>
> fork: record start_time late (2019-01-08 09:40:53 -0800)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git fixes-v5.0-rc1
>
> for you to fetch changes up to cba54b44d0be4eb66dbc7709e1f3f0d65e851f69:
>
> samples/seccomp: fix 32-bit build (2019-01-08 13:00:00 -0800)
>
> ----------------------------------------------------------------
>
> Tycho Andersen (1):
> samples/seccomp: fix 32-bit build
>
> samples/seccomp/Makefile | 1 +
> 1 file changed, 1 insertion(+)
>
> ---
>
> commit cba54b44d0be4eb66dbc7709e1f3f0d65e851f69
> Author: Tycho Andersen <tycho@tycho.ws>
> Date: Mon Jan 7 14:46:34 2019 -0700
>
> samples/seccomp: fix 32-bit build
>
> Both the .o and the actual executable need to be built with -m32 in order
> to link correctly.
>
> Fixes: fec7b6690541 ("samples: add an example of seccomp user trap")
>
> Signed-off-by: Tycho Andersen <tycho@tycho.ws>
> Reported-by: Ingo Molnar <mingo@kernel.org>
> Signed-off-by: James Morris <james.morris@microsoft.com>
>
> diff --git a/samples/seccomp/Makefile b/samples/seccomp/Makefile
> index 4920903c8009..a5607668a5c7 100644
> --- a/samples/seccomp/Makefile
> +++ b/samples/seccomp/Makefile
> @@ -37,6 +37,7 @@ HOSTCFLAGS_bpf-fancy.o += $(MFLAG)
> HOSTLDLIBS_bpf-direct += $(MFLAG)
> HOSTLDLIBS_bpf-fancy += $(MFLAG)
> HOSTLDLIBS_dropper += $(MFLAG)
> +HOSTLDLIBS_user-trap.o += $(MFLAG)
> HOSTLDLIBS_user-trap += $(MFLAG)
> endif
> always := $(hostprogs-m)
--
Kees Cook
^ permalink raw reply [relevance 92%]
* [GIT PULL] blob-stacking updates for security-next
@ 2019-01-08 21:35 73% Kees Cook
0 siblings, 1 reply; 200+ results
From: Kees Cook @ 2019-01-08 21:35 UTC (permalink / raw)
To: James Morris
Cc: linux-security-module, linux-kernel, Casey Schaufler,
John Johansen, Mickaël Salaün, Salvatore Mesoraca
Hi James,
Please pull these blob-stacking changes for security-next.
Thanks!
-Kees
The following changes since commit bfeffd155283772bbe78c6a05dec7c0128ee500c:
Linux 5.0-rc1 (2019-01-06 17:08:20 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/blob-stacking-security-next
for you to fetch changes up to a5e2fe7ede1268d2f80fe49ca1f717d0e3750995:
TOMOYO: Update LSM flags to no longer be exclusive (2019-01-08 13:18:45 -0800)
----------------------------------------------------------------
LSM: Module stacking for SARA and Landlock
The combined series of LSM refactoring and addition of blob-sharing for
SARA and Landlock.
----------------------------------------------------------------
Casey Schaufler (19):
LSM: Add all exclusive LSMs to ordered initialization
procfs: add smack subdir to attrs
Smack: Abstract use of cred security blob
SELinux: Abstract use of cred security blob
SELinux: Remove cred security blob poisoning
SELinux: Remove unused selinux_is_enabled
AppArmor: Abstract use of cred security blob
TOMOYO: Abstract use of cred security blob
Infrastructure management of the cred security blob
SELinux: Abstract use of file security blob
Smack: Abstract use of file security blob
LSM: Infrastructure management of the file security
SELinux: Abstract use of inode security blob
Smack: Abstract use of inode security blob
LSM: Infrastructure management of the inode security
LSM: Infrastructure management of the task security
SELinux: Abstract use of ipc security blobs
Smack: Abstract use of ipc security blobs
LSM: Infrastructure management of the ipc security blob
Kees Cook (19):
LSM: Introduce LSM_FLAG_LEGACY_MAJOR
LSM: Provide separate ordered initialization
LSM: Plumb visibility into optional "enabled" state
LSM: Lift LSM selection out of individual LSMs
LSM: Build ordered list of LSMs to initialize
LSM: Introduce CONFIG_LSM
LSM: Introduce "lsm=" for boottime LSM selection
LSM: Tie enabling logic to presence in ordered list
LSM: Prepare for reorganizing "security=" logic
LSM: Refactor "security=" in terms of enable/disable
LSM: Separate idea of "major" LSM from "exclusive" LSM
apparmor: Remove SECURITY_APPARMOR_BOOTPARAM_VALUE
selinux: Remove SECURITY_SELINUX_BOOTPARAM_VALUE
LSM: Split LSM preparation from initialization
LoadPin: Initialize as ordered LSM
Yama: Initialize as ordered LSM
LSM: Introduce enum lsm_order
capability: Initialize as LSM_ORDER_FIRST
TOMOYO: Update LSM flags to no longer be exclusive
Documentation/admin-guide/LSM/index.rst | 13 +-
Documentation/admin-guide/kernel-parameters.txt | 4 +
fs/proc/base.c | 64 ++-
fs/proc/internal.h | 1 +
include/linux/cred.h | 1 -
include/linux/lsm_hooks.h | 40 +-
include/linux/security.h | 15 +-
include/linux/selinux.h | 35 --
kernel/cred.c | 13 -
security/Kconfig | 41 +-
security/apparmor/Kconfig | 16 -
security/apparmor/domain.c | 2 +-
security/apparmor/include/cred.h | 16 +-
security/apparmor/include/file.h | 5 +-
security/apparmor/include/lib.h | 4 +
security/apparmor/include/task.h | 18 +-
security/apparmor/lsm.c | 65 ++-
security/apparmor/task.c | 6 +-
security/commoncap.c | 9 +-
security/loadpin/loadpin.c | 8 +-
security/security.c | 635 +++++++++++++++++++++---
security/selinux/Kconfig | 15 -
security/selinux/Makefile | 2 +-
security/selinux/exports.c | 23 -
security/selinux/hooks.c | 345 ++++---------
security/selinux/include/audit.h | 3 -
security/selinux/include/objsec.h | 38 +-
security/selinux/selinuxfs.c | 4 +-
security/selinux/ss/services.c | 1 -
security/selinux/xfrm.c | 4 +-
security/smack/smack.h | 44 +-
security/smack/smack_access.c | 4 +-
security/smack/smack_lsm.c | 316 ++++--------
security/smack/smackfs.c | 18 +-
security/tomoyo/common.h | 22 +-
security/tomoyo/domain.c | 4 +-
security/tomoyo/securityfs_if.c | 15 +-
security/tomoyo/tomoyo.c | 49 +-
security/yama/yama_lsm.c | 8 +-
39 files changed, 1133 insertions(+), 793 deletions(-)
delete mode 100644 include/linux/selinux.h
delete mode 100644 security/selinux/exports.c
--
Kees Cook
^ permalink raw reply [relevance 73%]
* [GIT PULL] lkdtm updates for -next
@ 2019-01-09 20:12 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2019-01-09 20:12 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-kernel, Christophe Leroy
Hi Greg,
Please pull these lkdtm changes for next (into, I assume, your
drivers-misc tree).
Thanks!
-Kees
The following changes since commit bfeffd155283772bbe78c6a05dec7c0128ee500c:
Linux 5.0-rc1 (2019-01-06 17:08:20 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/lkdtm-next
for you to fetch changes up to 59a12205d3c32aee4c13ca36889fdf7cfed31126:
lkdtm: Add tests for NULL pointer dereference (2019-01-09 12:00:31 -0800)
----------------------------------------------------------------
lkdtm updates and new tests
- Check NULL dereferences (Christophe Leroy)
- Print real addresses for debugging (Christophe Leroy)
- Drop CONFIG_BLOCK dependency
----------------------------------------------------------------
Christophe Leroy (2):
lkdtm: Print real addresses
lkdtm: Add tests for NULL pointer dereference
Kees Cook (1):
lkdtm: Do not depend on BLOCK and clean up headers
drivers/misc/lkdtm/core.c | 11 ++---------
drivers/misc/lkdtm/lkdtm.h | 2 ++
drivers/misc/lkdtm/perms.c | 36 +++++++++++++++++++++++++++---------
lib/Kconfig.debug | 1 -
4 files changed, 31 insertions(+), 19 deletions(-)
--
Kees Cook
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] blob-stacking updates for security-next
@ 2019-01-11 17:44 92% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2019-01-11 17:44 UTC (permalink / raw)
To: Tetsuo Handa
Cc: James Morris, Casey Schaufler, linux-security-module, LKML,
John Johansen, Mickaël Salaün, Salvatore Mesoraca
On Fri, Jan 11, 2019 at 2:38 AM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> On 2019/01/09 6:35, Kees Cook wrote:
> > Hi James,
> >
> > Please pull these blob-stacking changes for security-next.
> >
> > Thanks!
> >
> > -Kees
> >
> > The following changes since commit bfeffd155283772bbe78c6a05dec7c0128ee500c:
> >
> > Linux 5.0-rc1 (2019-01-06 17:08:20 -0800)
> >
> > are available in the Git repository at:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/blob-stacking-security-next
> >
> > for you to fetch changes up to a5e2fe7ede1268d2f80fe49ca1f717d0e3750995:
> >
> > TOMOYO: Update LSM flags to no longer be exclusive (2019-01-08 13:18:45 -0800)
> >
>
> And syzbot already found a bug.
> This is occurring immediately after memory allocation failure for cred object.
> We need to be prepared for free() function being called when alloc() function failed.
>
> [ 59.992498][ T8010] FAULT_INJECTION: forcing a failure.
> [ 59.992498][ T8010] name failslab, interval 1, probability 0, space 0, times 1
> [ 60.005214][ T8010] CPU: 0 PID: 8010 Comm: syz-executor178 Not tainted 5.0.0-rc1-next-20190111 #10
> [ 60.014337][ T8010] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> [ 60.024383][ T8010] Call Trace:
> [ 60.027657][ T8010] dump_stack+0x1db/0x2d0
> [ 60.063731][ T8010] should_fail.cold+0xa/0x14
> [ 60.089894][ T8010] __should_failslab+0x121/0x190
> [ 60.094810][ T8010] should_failslab+0x9/0x14
> [ 60.099411][ T8010] __kmalloc+0x2dc/0x740
> [ 60.124293][ T8010] security_prepare_creds+0x123/0x190
> [ 60.129644][ T8010] prepare_creds+0x3c4/0x510
> [ 60.149852][ T8010] __x64_sys_capset+0x58c/0x9b0
> [ 60.185347][ T8010] do_syscall_64+0x1a3/0x800
> [ 60.206747][ T8010] entry_SYSCALL_64_after_hwframe+0x49/0xbe
Are there more details on this crash report?
--
Kees Cook
^ permalink raw reply [relevance 92%]
* [GIT PULL] gcc-plugin fixes for v5.0-rc4
@ 2019-01-20 22:20 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2019-01-20 22:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Ard Biesheuvel, Kugan Vivekanandarajah
Hi Linus,
Please pull these gcc-plugin fixes for v5.0-rc4.
Thanks!
-Kees
The following changes since commit 1c7fc5cbc33980acd13d668f1c8f0313d6ae9fd8:
Linux 5.0-rc2 (2019-01-14 10:41:12 +1200)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/gcc-plugins-v5.0-rc4
for you to fetch changes up to 2c88c742d011707b55da7b54b06a030c6f57233f:
gcc-plugins: arm_ssp_per_task_plugin: fix for GCC 9+ (2019-01-20 14:06:40 -0800)
----------------------------------------------------------------
Bug fixes for gcc-plugins
- Fix ARM per-task stack protector plugin under GCC 9 (Ard Biesheuvel)
----------------------------------------------------------------
Ard Biesheuvel (2):
gcc-plugins: arm_ssp_per_task_plugin: sign extend the SP mask
gcc-plugins: arm_ssp_per_task_plugin: fix for GCC 9+
scripts/gcc-plugins/arm_ssp_per_task_plugin.c | 23 +++++++++++++++++++++--
1 file changed, 21 insertions(+), 2 deletions(-)
--
Kees Cook
^ permalink raw reply [relevance 92%]
* [GIT PULL] pstore fixes for v5.0-rc4
@ 2019-01-20 23:06 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2019-01-20 23:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Joel Fernandes, Sai Prakash Ranjan, Yue Hu
Hi Linus,
Please pull these pstore fixes for v5.0-rc4.
Thanks!
-Kees
The following changes since commit 1c7fc5cbc33980acd13d668f1c8f0313d6ae9fd8:
Linux 5.0-rc2 (2019-01-14 10:41:12 +1200)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/pstore-v5.0-rc4
for you to fetch changes up to 5631e8576a3caf606cdc375f97425a67983b420c:
pstore/ram: Avoid allocation and leak of platform data (2019-01-20 14:44:52 -0800)
----------------------------------------------------------------
Fixes for pstore/ram
- Fix console ramoops to show the previous boot logs (Sai Prakash Ranjan)
- Avoid allocation and leak of platform data
----------------------------------------------------------------
Kees Cook (1):
pstore/ram: Avoid allocation and leak of platform data
Sai Prakash Ranjan (1):
pstore/ram: Fix console ramoops to show the previous boot logs
fs/pstore/ram.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
--
Kees Cook
^ permalink raw reply [relevance 92%]
* [GIT PULL] pstore updates for v5.1-rc1
@ 2019-03-04 17:27 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2019-03-04 17:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Yue Hu
Hi Linus,
Please pull these pstore changes for v5.1-rc1. These are some small
cleanups mostly in the ramoops backend.
Thanks!
-Kees
The following changes since commit 49a57857aeea06ca831043acbb0fa5e0f50602fd:
Linux 5.0-rc3 (2019-01-21 13:14:44 +1300)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/pstore-v5.1-rc1
for you to fetch changes up to 93ee4b7d9f0632690713aee604c49e298e634094:
pstore/ram: Avoid needless alloc during header write (2019-02-12 13:45:53 -0800)
----------------------------------------------------------------
pstore cleanups
- Remove some needless memory allocations (Yue Hu, Kees Cook)
- Add zero-length checks to avoid no-op calls (Yue Hu)
----------------------------------------------------------------
Kees Cook (1):
pstore/ram: Avoid needless alloc during header write
Yue Hu (4):
pstore/ram: Replace dummy_data heap memory with stack memory
pstore: Avoid writing records with zero size
pstore/ram: Move initialization earlier
pstore/ram: Add kmsg hlen zero check to ramoops_pstore_write()
fs/pstore/platform.c | 3 +++
fs/pstore/ram.c | 64 ++++++++++++++++++++++++----------------------------
2 files changed, 32 insertions(+), 35 deletions(-)
--
Kees Cook
^ permalink raw reply [relevance 92%]
* [GIT PULL] gcc-plugin updates for v5.1-rc1
@ 2019-03-04 17:48 89% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2019-03-04 17:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Ard Biesheuvel
Hi Linus,
Please pull these gcc-plugin changes for v5.1-rc1. This adds additional
type coverage to the existing structleak plugin and adds a large set of
selftests to help evaluate stack variable zero-initialization coverage
(which can be used to test whatever instrumentation might be performing
zero-initialization: either with the structleak plugin or with Clang's
coming "-ftrivial-auto-var-init=zero" option).
Note that there is a minor conflict seen in linux-next with KASAN changes
in -mm, which removes the !KASAN_EXTRA depends from structleak. sfr's
resolution is correct:
https://lkml.kernel.org/r/20190213170345.656c3030@canb.auug.org.au
Thanks!
-Kees
The following changes since commit 49a57857aeea06ca831043acbb0fa5e0f50602fd:
Linux 5.0-rc3 (2019-01-21 13:14:44 +1300)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/gcc-plugins-v5.1-rc1
for you to fetch changes up to 50ceaa95ea09703722b30b4afa617c972071cd7f:
lib: Introduce test_stackinit module (2019-03-04 09:29:52 -0800)
----------------------------------------------------------------
increased structleak coverage
- And scalar and array initialization coverage
- Refactor Kconfig to make options more clear
- Add self-test module for testing automatic initialization
----------------------------------------------------------------
Kees Cook (2):
gcc-plugins: structleak: Generalize to all variable types
lib: Introduce test_stackinit module
lib/Kconfig.debug | 10 +
lib/Makefile | 1 +
lib/test_stackinit.c | 378 ++++++++++++++++++++++++++++++++
scripts/Makefile.gcc-plugins | 2 +
scripts/gcc-plugins/Kconfig | 58 ++++-
scripts/gcc-plugins/structleak_plugin.c | 36 ++-
6 files changed, 463 insertions(+), 22 deletions(-)
create mode 100644 lib/test_stackinit.c
--
Kees Cook
^ permalink raw reply [relevance 89%]
* Re: [GIT pull] x86/asm for 5.1
@ 2019-03-11 16:55 91% ` Kees Cook
0 siblings, 1 reply; 200+ results
From: Kees Cook @ 2019-03-11 16:55 UTC (permalink / raw)
To: Linus Torvalds
Cc: Thomas Gleixner, Linux List Kernel Mailing, the arch/x86 maintainers
On Mon, Mar 11, 2019 at 8:39 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> They are set early in the boot process, but they are set separately
> for each CPU, and not at the same time.
>
> And that's important. It's important because when the *first* CPU sets
> the "you now need to pin and check the SMAP bit", the _other_ CPU"s
> have not set it yet.
Clarification, just so I get the design considerations adjusted
correctly... I did this with a global because of the observation that
once CPU setup is done, the pin mask is the same for all CPUs.
However, yes, I see the point about the chosen implementation
resulting in a potential timing problem, etc. What about enabling the
pin mask once CPU init is finished? The goal is to protect those bits
during runtime (and to stay out of the way at init time).
I'll play with the "+r" memory output as a way to avoid volatile but
my earlier attempts at that did not produce machine code that was
actually defensive in the face of skipping the "or". (The cr0 case
works; I did use the "+r" method there. It's easy since it's a
hard-coded value -- I had less control over what the compiler decided
to do with register spilling in the cr4 case.)
Anyway, I'll work on a cleaner version and include you on CC.
Thanks!
--
Kees Cook
^ permalink raw reply [relevance 91%]
* Re: [GIT pull] x86/asm for 5.1
@ 2019-03-11 19:14 92% ` Kees Cook
[not found] ` <CAHk-=whQYG7iHO8Gv2Ka2_2tXNJkX1LdsyqKUZ=EO0aP6uS+2g@mail.gmail.com>
0 siblings, 1 reply; 200+ results
From: Kees Cook @ 2019-03-11 19:14 UTC (permalink / raw)
To: Linus Torvalds
Cc: Thomas Gleixner, Linux List Kernel Mailing, the arch/x86 maintainers
On Mon, Mar 11, 2019 at 10:41 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> Yes, that would fix things too, although I suspect you'll find that it
> gets hairy for hotplug CPU's (including suspend/resume), because new
> CPU's keep booting "forever".
In my testing, hotplug wasn't a problem because we'd already finished
cpu feature detection (which is why the SMEP/SMAP/UMIP bits couldn't
just be hard-coded). I had chosen to wait until after feature
detection was finished, etc.
> So what might be workable is to make 'cr4_init_shadow()' itself just
> do something like
>
> this_cpu_write(cpu_tlbstate.cr4, __read_cr4() | cr4_pin);
>
> but I did *not* check whether there might be some other random
> accesses to %cr4 in various legacy paths..
The protection needs to be around the actual "mov %rdi, %cr4" that
native_write_cr4() exposes, so the "or" can't really be placed
earlier. Anyway, I'll examine some options. Thomas also suggested
looking at static keys, etc. I'll play around with it.
--
Kees Cook
^ permalink raw reply [relevance 92%]
* Re: [GIT pull] x86/asm for 5.1
[not found] ` <CAHk-=whQYG7iHO8Gv2Ka2_2tXNJkX1LdsyqKUZ=EO0aP6uS+2g@mail.gmail.com>
@ 2019-03-11 20:36 92% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2019-03-11 20:36 UTC (permalink / raw)
To: Linus Torvalds
Cc: Thomas Gleixner, Linux List Kernel Mailing, the arch/x86 maintainers
On Mon, Mar 11, 2019 at 12:23 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Mon, Mar 11, 2019, 12:14 Kees Cook <keescook@chromium.org> wrote:
>>
>> >
>> > this_cpu_write(cpu_tlbstate.cr4, __read_cr4() | cr4_pin);
>> >
>> ..
>>
>> The protection needs to be around the actual "mov %rdi, %cr4" that
>> native_write_cr4() exposes,
>
>
> You misunderstand.
>
> The above is just the "initialise cr4 shadow cache" case.
>
> If you do the above, I think we may have cr4 values initialled early enough that all CPUs can then just use the "check that the pinned bits were set" unconditionally in the actual routine that changes cr4.
Oh! I see what you mean -- separate the or and test. Okay, I'll look
at that too.
--
Kees Cook
^ permalink raw reply [relevance 92%]
* [GIT PULL] seccomp fixes for v5.1-rc8
@ 2019-04-29 19:58 91% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2019-04-29 19:58 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, James Morris, syzbot+b562969adb2e04af3442, Tycho Andersen
Hi Linus,
Please pull these seccomp fixes for v5.1-rc8. Syzbot found a use-after-free
bug in seccomp due to flags that should not be allowed to be used together.
Tycho fixed this, I updated the self-tests, and the syzkaller PoC has been
running for several days without triggering KASan (before this fix, it
would reproduce). These patches have also been in -next for almost a week,
just to be sure.
Thanks!
-Kees
The following changes since commit 8c2ffd9174779014c3fe1f96d9dc3641d9175f00:
Linux 5.1-rc2 (2019-03-24 14:02:26 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-v5.1-rc8
for you to fetch changes up to 7a0df7fbc14505e2e2be19ed08654a09e1ed5bf6:
seccomp: Make NEW_LISTENER and TSYNC flags exclusive (2019-04-25 15:55:58 -0700)
----------------------------------------------------------------
seccomp use-after-free fix
- Add logic for making some seccomp flags exclusive (Tycho)
- Update selftests for exclusivity testing (Kees)
----------------------------------------------------------------
Kees Cook (1):
selftests/seccomp: Prepare for exclusive seccomp flags
Tycho Andersen (1):
seccomp: Make NEW_LISTENER and TSYNC flags exclusive
kernel/seccomp.c | 17 ++++++++++++--
tools/testing/selftests/seccomp/seccomp_bpf.c | 34 ++++++++++++++++++++-------
2 files changed, 40 insertions(+), 11 deletions(-)
--
Kees Cook
^ permalink raw reply [relevance 91%]
* [GIT PULL] compiler-based variable-init updates for v5.2-rc1
@ 2019-05-06 17:21 91% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2019-05-06 17:21 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Alexander Popov, Alexander Potapenko, Masahiro Yamada
Hi Linus,
Please pull these changes for v5.2-rc1. This is effectively part of my
gcc-plugins tree, but as this adds some Clang support, it felt weird
to still call it "gcc-plugins". :) This consolidates Kconfig for the
existing stack variable initialization (via structleak and stackleak
gcc plugins) and adds Alexander Potapenko's support for Clang's new
similar functionality.
Thanks!
-Kees
The following changes since commit 8c2ffd9174779014c3fe1f96d9dc3641d9175f00:
Linux 5.1-rc2 (2019-03-24 14:02:26 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/meminit-v5.2-rc1
for you to fetch changes up to 709a972efb01efaeb97cad1adc87fe400119c8ab:
security: Implement Clang's stack initialization (2019-04-24 14:00:56 -0700)
----------------------------------------------------------------
compiler-based memory initialization
- Consolidate memory initialization Kconfigs (Kees)
- Implement support for Clang's stack variable auto-init (Alexander)
----------------------------------------------------------------
Kees Cook (3):
security: Create "kernel hardening" config area
security: Move stackleak config to Kconfig.hardening
security: Implement Clang's stack initialization
Makefile | 5 ++
scripts/gcc-plugins/Kconfig | 126 ++--------------------------------
security/Kconfig | 2 +
security/Kconfig.hardening | 164 ++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 177 insertions(+), 120 deletions(-)
create mode 100644 security/Kconfig.hardening
--
Kees Cook
^ permalink raw reply [relevance 91%]
* [GIT PULL] lkdtm fixes for next
@ 2019-05-09 17:19 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2019-05-09 17:19 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-kernel
Hi Greg,
Please pull these lkdtm fixes for next. If possible, it'd be nice to get
these into v5.2 (they're small fixes), but I'm fine if they have to wait.
I meant to send these earlier, but got distracted by other things.
Thanks!
-Kees
The following changes since commit 8c2ffd9174779014c3fe1f96d9dc3641d9175f00:
Linux 5.1-rc2 (2019-03-24 14:02:26 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/lkdtm-next
for you to fetch changes up to 24cccab42c4199c6daa0a6981e6f6a1ffb0b5a09:
lkdtm/bugs: Adjust recursion test to avoid elision (2019-04-07 10:38:31 -0700)
----------------------------------------------------------------
lkdtm: various fixes
- Move KERNEL_DS test to non-canonical range
- Make stack exhaustion test more robust
----------------------------------------------------------------
Kees Cook (2):
lkdtm/usercopy: Moves the KERNEL_DS test to non-canonical
lkdtm/bugs: Adjust recursion test to avoid elision
drivers/misc/lkdtm/bugs.c | 23 +++++++++++++++++------
drivers/misc/lkdtm/core.c | 6 +++---
drivers/misc/lkdtm/lkdtm.h | 2 +-
drivers/misc/lkdtm/usercopy.c | 10 ++++++----
4 files changed, 27 insertions(+), 14 deletions(-)
--
Kees Cook
^ permalink raw reply [relevance 92%]
* [GIT PULL] gcc-plugins fixes for v5.2-rc1
@ 2019-05-13 21:05 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2019-05-13 21:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Chris Packham, Douglas Anderson
Hi Linus,
Please pull this build (with older GCC < 6) fix for the ARM
stack-protector-per-task plugin for v5.2-rc1.
Thanks!
-Kees
The following changes since commit e93c9c99a629c61837d5a7fc2120cd2b6c70dbdd:
Linux 5.1 (2019-05-05 17:42:58 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/gcc-plugins-v5.2-rc1
for you to fetch changes up to 259799ea5a9aa099a267f3b99e1f7078bbaf5c5e:
gcc-plugins: arm_ssp_per_task_plugin: Fix for older GCC < 6 (2019-05-10 15:35:01 -0700)
----------------------------------------------------------------
gcc-plugin fix:
- ARM stack-protector-per-task plugin: Fix for older GCC < 6 (Chris Packham)
----------------------------------------------------------------
Chris Packham (1):
gcc-plugins: arm_ssp_per_task_plugin: Fix for older GCC < 6
scripts/gcc-plugins/arm_ssp_per_task_plugin.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
Kees Cook
^ permalink raw reply [relevance 92%]
* [GIT PULL] gcc-plugins update for v5.2-rc3
@ 2019-05-31 2:18 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2019-05-31 2:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, H. Nikolaus Schaller
Hi Linus,
Please pull this gcc-plugins fix for v5.2-rc3. This has lived in
linux-next for about a week now.
Thanks!
-Kees
The following changes since commit 259799ea5a9aa099a267f3b99e1f7078bbaf5c5e:
gcc-plugins: arm_ssp_per_task_plugin: Fix for older GCC < 6 (2019-05-10 15:35:01 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/gcc-plugins-v5.2-rc3
for you to fetch changes up to 7210e060155b9cf557fb13128353c3e494fa5ed3:
gcc-plugins: Fix build failures under Darwin host (2019-05-20 13:30:54 -0700)
----------------------------------------------------------------
gcc-plugins: Handle unusual header environment
- Fix redefined macro error under a Darwin build host
----------------------------------------------------------------
Kees Cook (1):
gcc-plugins: Fix build failures under Darwin host
scripts/gcc-plugins/gcc-common.h | 4 ++++
1 file changed, 4 insertions(+)
--
Kees Cook
^ permalink raw reply [relevance 92%]
* [GIT PULL] pstore fixes for v5.2-rc4
@ 2019-06-05 3:20 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2019-06-05 3:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Kees Cook, Pi-Hsun Shih, stable
Hi Linus,
Please pull these pstore fixes for v5.2-rc4. They've been in linux-next
for a bit now and catch some pstore corner cases found recently.
Thanks!
-Kees
The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9:
Linux 5.2-rc1 (2019-05-19 15:47:09 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/pstore-v5.2-rc4
for you to fetch changes up to 8880fa32c557600f5f624084152668ed3c2ea51e:
pstore/ram: Run without kernel crash dump region (2019-05-31 01:19:06 -0700)
----------------------------------------------------------------
pstore fixes for v5.2-rc4
- Avoid NULL deref when unloading/reloading ramoops module (Pi-Hsun Shih)
- Run ramoops without crash dump region
----------------------------------------------------------------
Kees Cook (1):
pstore/ram: Run without kernel crash dump region
Pi-Hsun Shih (1):
pstore: Set tfm to NULL on free_buf_for_compression
fs/pstore/platform.c | 7 +++++--
fs/pstore/ram.c | 36 +++++++++++++++++++++++-------------
2 files changed, 28 insertions(+), 15 deletions(-)
--
Kees Cook
^ permalink raw reply [relevance 92%]
* [GIT PULL] meminit fix for v5.2-rc6
@ 2019-06-18 4:00 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2019-06-18 4:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Ard Biesheuvel
Hi Linus,
Please pull this fix for what I'm calling "meminit" (the compiler-based
variable-init stuff) for v5.2-rc6. This is a small update to the stack
auto-initialization self-test code to deal with the Clang initialization
pattern. It's been in linux-next for a couple weeks; I had waited a bit
wondering if anything more substantial was going to show up, but nothing
has, so I'm sending this now before it gets too late.
Thanks!
-Kees
The following changes since commit f2c7c76c5d0a443053e94adb9f0918fa2fb85c3a:
Linux 5.2-rc3 (2019-06-02 13:55:33 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/meminit-v5.2-rc6
for you to fetch changes up to 8c30d32b1a326bb120635a8b4836ec61cba454fa:
lib/test_stackinit: Handle Clang auto-initialization pattern (2019-06-05 07:36:43 -0700)
----------------------------------------------------------------
compiler-based memory initialization update
- Update stack auto-initialization selftest for Clang initialization pattern
----------------------------------------------------------------
Kees Cook (1):
lib/test_stackinit: Handle Clang auto-initialization pattern
lib/test_stackinit.c | 21 +++++++++++++++------
1 file changed, 15 insertions(+), 6 deletions(-)
--
Kees Cook
^ permalink raw reply [relevance 92%]
* [GIT PULL] pstore updates for v5.3-rc1
@ 2019-07-09 4:11 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2019-07-09 4:11 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Anton Vorontsov, Colin Cross, Douglas Anderson,
Greg Kroah-Hartman, Kees Cook, Norbert Manthey, Tony Luck
Hi Linus,
Please pull these pstore updates for v5.3-rc1. Details below...
Thanks!
-Kees
The following changes since commit d1fdb6d8f6a4109a4263176c84b899076a5f8008:
Linux 5.2-rc4 (2019-06-08 20:24:46 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/pstore-v5.3-rc1
for you to fetch changes up to 4c6d80e1144bdf48cae6b602ae30d41f3e5c76a9:
pstore: Fix double-free in pstore_mkfile() failure path (2019-07-08 21:04:42 -0700)
----------------------------------------------------------------
pstore improvements
- Improve backward compatibility with older Chromebooks (Douglas Anderson)
- Refactor debugfs initialization (Greg KH)
- Fix double-free in pstore_mkfile() failure path (Norbert Manthey)
----------------------------------------------------------------
Douglas Anderson (1):
pstore/ram: Improve backward compatibility with older Chromebooks
Greg Kroah-Hartman (1):
pstore: no need to check return value of debugfs_create functions
Norbert Manthey (1):
pstore: Fix double-free in pstore_mkfile() failure path
fs/pstore/ftrace.c | 18 ++----------------
fs/pstore/inode.c | 13 ++++++-------
fs/pstore/ram.c | 21 +++++++++++++++++++++
3 files changed, 29 insertions(+), 23 deletions(-)
--
Kees Cook
^ permalink raw reply [relevance 92%]
* [GIT PULL] loadpin update for v5.3-rc1
@ 2019-07-09 4:18 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2019-07-09 4:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, James Morris, Kees Cook, Ke Wu
Hi Linus,
Please pull this loadpin update for v5.3-rc1. Details below...
Thanks!
-Kees
The following changes since commit cd6c84d8f0cdc911df435bb075ba22ce3c605b07:
Linux 5.2-rc2 (2019-05-26 16:49:19 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/loadpin-v5.3-rc1
for you to fetch changes up to 0ff9848067b7b950a4ed70de7f5028600a2157e3:
security/loadpin: Allow to exclude specific file types (2019-05-31 13:57:40 -0700)
----------------------------------------------------------------
security/loadpin improvement
- Allow exclusion of specific file types (Ke Wu)
----------------------------------------------------------------
Ke Wu (1):
security/loadpin: Allow to exclude specific file types
Documentation/admin-guide/LSM/LoadPin.rst | 10 +++++++
security/loadpin/loadpin.c | 48 +++++++++++++++++++++++++++++++
2 files changed, 58 insertions(+)
--
Kees Cook
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] x86/topology changes for v5.3
@ 2019-07-10 0:31 92% ` Kees Cook
0 siblings, 1 reply; 200+ results
From: Kees Cook @ 2019-07-10 0:31 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Linus Torvalds, Ingo Molnar, Linux List Kernel Mailing,
Borislav Petkov, Len Brown, Peter Zijlstra, Andrew Morton,
Rafael J. Wysocki, Tony Luck, Jiri Kosina, Bob Moore,
Erik Schmauss
On Wed, Jul 10, 2019 at 01:17:11AM +0200, Thomas Gleixner wrote:
> On Wed, 10 Jul 2019, Thomas Gleixner wrote:
> >
> > That still does not explain the cr4/0 issue you have. Can you send me your
> > .config please?
>
> Does your machine have UMIP support? None of my test boxes has. So that'd
> be the difference of bits enforced in CR4. Should not matter because it's
> User mode instruction prevention, but who knows.
Ew. Yeah, I don't have i9 nor i7 for testing this. I did try everything
else I had (and hibernation). Is only Linus able to reproduce this so far?
To rule out (in?) UMIP, this would remove UMIP from the pinning:
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 309b6b9b49d4..f3beedb6da8a 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -380,7 +380,7 @@ static void __init setup_cr_pinning(void)
{
unsigned long mask;
- mask = (X86_CR4_SMEP | X86_CR4_SMAP | X86_CR4_UMIP);
+ mask = (X86_CR4_SMEP | X86_CR4_SMAP);
cr4_pinned_bits = this_cpu_read(cpu_tlbstate.cr4) & mask;
static_key_enable(&cr_pinning.key);
}
--
Kees Cook
^ permalink raw reply related [relevance 92%]
* Re: [GIT PULL] x86/topology changes for v5.3
@ 2019-07-10 5:33 92% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2019-07-10 5:33 UTC (permalink / raw)
To: Linus Torvalds
Cc: Thomas Gleixner, Ingo Molnar, Linux List Kernel Mailing,
Borislav Petkov, Len Brown, Peter Zijlstra, Andrew Morton,
Rafael J. Wysocki, Tony Luck, Jiri Kosina, Bob Moore,
Erik Schmauss
On Tue, Jul 09, 2019 at 10:15:21PM -0700, Linus Torvalds wrote:
> On Tue, Jul 9, 2019 at 8:21 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > Whee. It looks like it's bisecting to the same thing. Only partway
> > done, but it feels very much like my desktop.
>
> Confirmed.
>
> With that config, I get this
>
> c21ac93288f0 (refs/bisect/bad) Merge tag 'v5.2-rc6' into x86/asm, to
> refresh the branch
> 8dbec27a242c (HEAD) x86/asm: Pin sensitive CR0 bits
> 873d50d58f67 x86/asm: Pin sensitive CR4 bits
>
> ie those "pin sensitive bits" merge is bad, but before the commits is good.
>
> I think there is _another_ problem too, and maybe it's the APCI one,
> but this one triggers some issue before the other issue even gets to
> play..
Okay, fun. Thanks for confirming it. Well, I guess I get to try to
find some more modern hardware to track this down. Does booting with
init=/bin/sh get far enough to see if all the CPUs are online or anything
like that? I'm baffled about the "gets mostly to userspace" part. I'd
expect this to explode very badly if it misbehaved. Or maybe something
gets confused between how many CPUs are expected and how many actually
show up to the party. Hmmm.
--
Kees Cook
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] x86/topology changes for v5.3
@ 2019-07-11 15:08 92% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2019-07-11 15:08 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Nadav Amit, Jiri Kosina, Xi Ruoyao, Thomas Gleixner,
Linus Torvalds, Ingo Molnar, Linux List Kernel Mailing,
Borislav Petkov, Len Brown, Andrew Morton, Rafael J. Wysocki,
Tony Luck, Bob Moore, Erik Schmauss, Josh Poimboeuf,
Daniel Bristot de Oliveira
On Thu, Jul 11, 2019 at 10:01:34AM +0200, Peter Zijlstra wrote:
> On Thu, Jul 11, 2019 at 07:11:19AM +0000, Nadav Amit wrote:
> > > On Jul 10, 2019, at 7:22 AM, Jiri Kosina <jikos@kernel.org> wrote:
> > >
> > > On Wed, 10 Jul 2019, Peter Zijlstra wrote:
> > >
> > >> If we mark the key as RO after init, and then try and modify the key to
> > >> link module usage sites, things might go bang as described.
> > >>
> > >> Thanks!
> > >>
> > >>
> > >> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> > >> index 27d7864e7252..5bf7a8354da2 100644
> > >> --- a/arch/x86/kernel/cpu/common.c
> > >> +++ b/arch/x86/kernel/cpu/common.c
> > >> @@ -366,7 +366,7 @@ static __always_inline void setup_umip(struct cpuinfo_x86 *c)
> > >> cr4_clear_bits(X86_CR4_UMIP);
> > >> }
> > >>
> > >> -DEFINE_STATIC_KEY_FALSE_RO(cr_pinning);
> > >> +DEFINE_STATIC_KEY_FALSE(cr_pinning);
> > >
> > > Good catch, I guess that is going to fix it.
> > >
> > > At the same time though, it sort of destroys the original intent of Kees'
> > > patch, right? The exploits will just have to call static_key_disable()
> > > prior to calling native_write_cr4() again, and the protection is gone.
> >
> > Even with DEFINE_STATIC_KEY_FALSE_RO(), I presume you can just call
> > set_memory_rw(), make the page that holds the key writable, and then call
> > static_key_disable(), followed by a call to native_write_cr4().
>
> Or call text_poke_bp() with the right set of arguments.
Right -- the point is to make it defended against an arbitrary write,
not arbitrary execution. Nothing is safe from arbitrary exec, but we can
do our due diligence on making things read-only.
--
Kees Cook
^ permalink raw reply [relevance 92%]
* [GIT PULL] meminit fix for v5.3-rc2
@ 2019-07-28 19:21 92% Kees Cook
0 siblings, 1 reply; 200+ results
From: Kees Cook @ 2019-07-28 19:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Arnd Bergmann
Hi Linus,
Please pull this meminit fix for v5.3-rc2. This is late in the -rc2
window because I got confused about whether I or akpm was taking this
patch. I noticed it still wasn't in -mm, so here it is. It's a small
Kconfig change that fixes a bunch of build warnings under KASAN and the
gcc-plugin-based stack auto-initialization features (which are arguably
redundant, so better to let KASAN control this).
Thanks!
-Kees
The following changes since commit cd6c84d8f0cdc911df435bb075ba22ce3c605b07:
Linux 5.2-rc2 (2019-05-26 16:49:19 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/meminit-v5.3-rc2
for you to fetch changes up to 173e6ee21e2b3f477f07548a79c43b8d9cfbb37d:
structleak: disable STRUCTLEAK_BYREF in combination with KASAN_STACK (2019-07-25 16:16:12 -0700)
----------------------------------------------------------------
meminit fix
- Disable gcc-based stack variable auto-init under KASAN (Arnd Bergmann)
----------------------------------------------------------------
Arnd Bergmann (1):
structleak: disable STRUCTLEAK_BYREF in combination with KASAN_STACK
security/Kconfig.hardening | 7 +++++++
1 file changed, 7 insertions(+)
--
Kees Cook
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] meminit fix for v5.3-rc2
@ 2019-07-28 22:16 92% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2019-07-28 22:16 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux List Kernel Mailing, Arnd Bergmann, Alexander Potapenko
On Sun, Jul 28, 2019 at 12:43:15PM -0700, Linus Torvalds wrote:
> On Sun, Jul 28, 2019 at 12:21 PM Kees Cook <keescook@chromium.org> wrote:
> >
> > Please pull this meminit fix for v5.3-rc2.
>
> Side noe: I find "meminit" a confusing description for the structleak
> thing. When I hear it, it sounds like some generic memory
> initialization thing in the VM layer (which we obviously do also
> have), not the stack variable initialization.
I will find a better name. :) We dreamed up "meminit" as finding a name
for the umbrella of both stack and heap auto-initialization. But I
agree, it's confusing.
> Also, have you guys talked to gcc people about just making it a real
> feature, like I think it is for clang? In particular, I still suspect
> that we could/should just make zero-filling the *default* in the long
> run, and say "our C standard is that local variables are initialized
> to zero, exactly the same way static variables are".
Yes, this is on the list for discussion at Plumber's. Having gcc do
auto-init is the first part. Convincing Clang that _zero_ init isn't
a language-breaking change is the second part. :P That's been a whole
other issue.
> I know you posted some numbers somewhere (well, I'm pretty sure you
> did) and the full stack initialization really was pretty cheap,
> wasn't it?
Yes, Clang's initialization (which is 0xAA not 0x00 in most cases) is
cheap. There are rumors(?) of some pathological workloads, though. I
haven't seen real numbers for that though.
I'll try to find the Clang numbers (maybe Alexander has them?) but I
remember it being the same as (or maybe better than) the gcc-plugin
version, which I measured here:
https://git.kernel.org/linus/81a56f6dcd20
--
Kees Cook
^ permalink raw reply [relevance 92%]
* [GIT PULL drivers/misc] lkdtm updates for next
@ 2019-08-25 22:23 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2019-08-25 22:23 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-kernel, Kees Cook
Hi Greg,
Please pull these LKDTM updates for next.
Thanks!
-Kees
The following changes since commit 609488bc979f99f805f34e9a32c1e3b71179d10b:
Linux 5.3-rc2 (2019-07-28 12:47:02 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/lkdtm-next
for you to fetch changes up to 1ee170ea3f0dcf3a4b34f7e7c36559e84bb0d3d6:
lkdtm: Split WARNING into separate tests (2019-08-19 11:13:21 -0700)
----------------------------------------------------------------
Updates to LKDTM for -next
- split WARNING into two tests: with message and without
- add prototype-granularity forward CFI test
----------------------------------------------------------------
Kees Cook (2):
lkdtm: Add Control Flow Integrity test
lkdtm: Split WARNING into separate tests
drivers/misc/lkdtm/Makefile | 1 +
drivers/misc/lkdtm/bugs.c | 7 ++++++-
drivers/misc/lkdtm/cfi.c | 42 ++++++++++++++++++++++++++++++++++++++++++
drivers/misc/lkdtm/core.c | 2 ++
drivers/misc/lkdtm/lkdtm.h | 4 ++++
5 files changed, 55 insertions(+), 1 deletion(-)
create mode 100644 drivers/misc/lkdtm/cfi.c
--
Kees Cook
^ permalink raw reply [relevance 92%]
* [GIT PULL] gcc-plugins update for v5.4-rc1
@ 2019-09-16 21:44 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2019-09-16 21:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Joonwon Kang, Kees Cook
Hi Linus,
Please pull this tiny gcc-plugins update for v5.4-rc1. It fixes a
potential problem in structure auto-selection (that was not triggered by
any existing kernel structures). This has been in linux-next for about 5
weeks.
Thanks!
-Kees
The following changes since commit 609488bc979f99f805f34e9a32c1e3b71179d10b:
Linux 5.3-rc2 (2019-07-28 12:47:02 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/gcc-plugins-v5.4-rc1
for you to fetch changes up to 60f2c82ed20bde57c362e66f796cf9e0e38a6dbb:
randstruct: Check member structs in is_pure_ops_struct() (2019-07-31 13:13:22 -0700)
----------------------------------------------------------------
randomize_layout: Fix potential auto-selection bug
- Fix auto-selection bug in is_pure_ops_struct (Joonwon Kang)
----------------------------------------------------------------
Joonwon Kang (1):
randstruct: Check member structs in is_pure_ops_struct()
scripts/gcc-plugins/randomize_layout_plugin.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--
Kees Cook
^ permalink raw reply [relevance 92%]
* [GIT PULL] treewide conversion to sizeof_member() for v5.4-rc1
@ 2019-09-26 17:33 61% Kees Cook
0 siblings, 1 reply; 200+ results
From: Kees Cook @ 2019-09-26 17:33 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Kees Cook, Pankaj Bharadiya, Joe Perches, Alexey Dobriyan
Hi Linus,
Please pull this mostly mechanical treewide conversion to the single and
more accurately named sizeof_member() macro for the end of v5.4-rc1. This
replaces 3 macros of the same behavior (FIELD_SIZEOF(), SIZEOF_FIELD(),
and sizeof_field()). The last patch in the series has a script in the
commit log to do the conversion, if you want to compare the results
(they remained identical today when I checked).
Thanks!
-Kees
The following changes since commit 4c07e2ddab5b6b57dbcb09aedbda1f484d5940cc:
Merge tag 'mfd-next-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd (2019-09-23 19:37:49 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/sizeof_member-v5.4-rc1
for you to fetch changes up to 32f8b3ead0cb8f98edc76b72ee987a259f889736:
treewide: Use sizeof_member() macro (2019-09-24 09:55:31 -0700)
----------------------------------------------------------------
Treewide conversion to sizeof_member() for struct member size calculations
----------------------------------------------------------------
Pankaj Bharadiya (3):
linux/stddef.h: Add sizeof_member() macro
MIPS: OCTEON: Remove SIZEOF_FIELD() macro
treewide: Use sizeof_member() macro
Documentation/process/coding-style.rst | 2 +-
.../translations/it_IT/process/coding-style.rst | 2 +-
.../translations/zh_CN/process/coding-style.rst | 2 +-
arch/arc/kernel/unwind.c | 6 +-
arch/arm64/include/asm/processor.h | 10 +-
arch/mips/cavium-octeon/executive/cvmx-bootmem.c | 9 +-
arch/powerpc/net/bpf_jit32.h | 4 +-
arch/powerpc/net/bpf_jit_comp.c | 16 +--
arch/sparc/net/bpf_jit_comp_32.c | 8 +-
arch/x86/kernel/fpu/xstate.c | 2 +-
block/blk-core.c | 4 +-
crypto/adiantum.c | 4 +-
crypto/essiv.c | 2 +-
drivers/firmware/efi/efi.c | 2 +-
drivers/gpu/drm/i915/gvt/scheduler.c | 2 +-
drivers/infiniband/hw/efa/efa_verbs.c | 2 +-
drivers/infiniband/hw/hfi1/sdma.c | 2 +-
drivers/infiniband/hw/hfi1/verbs.h | 4 +-
drivers/infiniband/ulp/opa_vnic/opa_vnic_ethtool.c | 2 +-
drivers/input/keyboard/applespi.c | 2 +-
drivers/md/raid5-ppl.c | 2 +-
drivers/media/platform/omap3isp/isppreview.c | 24 ++--
drivers/net/ethernet/amd/xgbe/xgbe-ethtool.c | 4 +-
.../net/ethernet/cavium/liquidio/octeon_console.c | 16 +--
drivers/net/ethernet/emulex/benet/be_ethtool.c | 2 +-
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 2 +-
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c | 2 +-
drivers/net/ethernet/huawei/hinic/hinic_ethtool.c | 8 +-
drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c | 2 +-
drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 2 +-
drivers/net/ethernet/intel/i40e/i40e_lan_hmc.c | 2 +-
drivers/net/ethernet/intel/iavf/iavf_ethtool.c | 2 +-
drivers/net/ethernet/intel/ice/ice_ethtool.c | 10 +-
drivers/net/ethernet/intel/ice/ice_lan_tx_rx.h | 2 +-
drivers/net/ethernet/intel/igb/igb_ethtool.c | 4 +-
drivers/net/ethernet/intel/igc/igc_ethtool.c | 4 +-
drivers/net/ethernet/intel/ixgb/ixgb_ethtool.c | 4 +-
drivers/net/ethernet/intel/ixgbevf/ethtool.c | 4 +-
drivers/net/ethernet/marvell/mv643xx_eth.c | 4 +-
drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 2 +-
.../net/ethernet/mellanox/mlx5/core/fpga/ipsec.c | 6 +-
drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 4 +-
drivers/net/ethernet/mellanox/mlxsw/spectrum_fid.c | 4 +-
drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.c | 2 +-
drivers/net/ethernet/netronome/nfp/bpf/jit.c | 10 +-
drivers/net/ethernet/netronome/nfp/bpf/main.c | 2 +-
drivers/net/ethernet/netronome/nfp/bpf/offload.c | 2 +-
drivers/net/ethernet/netronome/nfp/flower/main.h | 2 +-
.../ethernet/oki-semi/pch_gbe/pch_gbe_ethtool.c | 2 +-
drivers/net/ethernet/qlogic/qede/qede.h | 2 +-
.../net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c | 2 +-
drivers/net/ethernet/samsung/sxgbe/sxgbe_ethtool.c | 2 +-
.../net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 4 +-
drivers/net/ethernet/ti/cpsw_ethtool.c | 6 +-
drivers/net/ethernet/ti/netcp_ethss.c | 32 ++---
drivers/net/fjes/fjes_ethtool.c | 2 +-
drivers/net/geneve.c | 2 +-
drivers/net/hyperv/netvsc_drv.c | 2 +-
drivers/net/usb/sierra_net.c | 2 +-
drivers/net/usb/usbnet.c | 2 +-
drivers/net/vxlan.c | 4 +-
drivers/net/wireless/marvell/libertas/debugfs.c | 2 +-
drivers/net/wireless/marvell/mwifiex/util.h | 4 +-
drivers/s390/net/qeth_core_mpc.h | 10 +-
drivers/scsi/aacraid/aachba.c | 4 +-
drivers/scsi/be2iscsi/be_cmds.h | 2 +-
drivers/scsi/cxgbi/libcxgbi.c | 2 +-
drivers/scsi/smartpqi/smartpqi_init.c | 6 +-
drivers/staging/qlge/qlge_ethtool.c | 2 +-
drivers/target/iscsi/cxgbit/cxgbit_main.c | 2 +-
drivers/usb/atm/usbatm.c | 2 +-
drivers/usb/gadget/function/f_fs.c | 2 +-
fs/befs/linuxvfs.c | 2 +-
fs/crypto/keyring.c | 2 +-
fs/ext2/super.c | 2 +-
fs/ext4/super.c | 2 +-
fs/freevxfs/vxfs_super.c | 2 +-
fs/orangefs/super.c | 2 +-
fs/ufs/super.c | 2 +-
fs/verity/enable.c | 2 +-
include/linux/filter.h | 12 +-
include/linux/kvm_host.h | 2 +-
include/linux/phy_led_triggers.h | 2 +-
include/linux/slab.h | 2 +-
include/linux/stddef.h | 13 +-
include/net/garp.h | 2 +-
include/net/ip_tunnels.h | 6 +-
include/net/mrp.h | 2 +-
include/net/netfilter/nf_conntrack_helper.h | 2 +-
include/net/netfilter/nf_tables_core.h | 2 +-
include/net/sock.h | 2 +-
ipc/util.c | 2 +-
kernel/bpf/cgroup.c | 2 +-
kernel/bpf/local_storage.c | 4 +-
kernel/fork.c | 2 +-
kernel/signal.c | 12 +-
kernel/utsname.c | 2 +-
net/802/mrp.c | 6 +-
net/batman-adv/main.c | 2 +-
net/bpf/test_run.c | 6 +-
net/bridge/br.c | 2 +-
net/caif/caif_socket.c | 2 +-
net/core/dev.c | 2 +-
net/core/filter.c | 140 ++++++++++-----------
net/core/flow_dissector.c | 10 +-
net/core/skbuff.c | 2 +-
net/core/xdp.c | 4 +-
net/dccp/proto.c | 2 +-
net/ipv4/ip_gre.c | 4 +-
net/ipv4/ip_vti.c | 4 +-
net/ipv4/raw.c | 2 +-
net/ipv4/tcp.c | 2 +-
net/ipv6/ip6_gre.c | 4 +-
net/ipv6/raw.c | 2 +-
net/iucv/af_iucv.c | 2 +-
net/netfilter/nf_tables_api.c | 4 +-
net/netfilter/nfnetlink_cthelper.c | 2 +-
net/netfilter/nft_ct.c | 12 +-
net/netfilter/nft_masq.c | 2 +-
net/netfilter/nft_nat.c | 6 +-
net/netfilter/nft_redir.c | 2 +-
net/netfilter/nft_tproxy.c | 4 +-
net/netfilter/xt_RATEEST.c | 2 +-
net/netlink/af_netlink.c | 2 +-
net/openvswitch/datapath.c | 2 +-
net/openvswitch/flow.h | 4 +-
net/rxrpc/af_rxrpc.c | 2 +-
net/sched/act_ct.c | 4 +-
net/sched/cls_flower.c | 2 +-
net/sctp/socket.c | 4 +-
net/unix/af_unix.c | 2 +-
security/integrity/ima/ima_policy.c | 4 +-
sound/soc/codecs/hdmi-codec.c | 2 +-
tools/testing/selftests/bpf/bpf_util.h | 6 +-
virt/kvm/kvm_main.c | 2 +-
135 files changed, 341 insertions(+), 337 deletions(-)
--
Kees Cook
^ permalink raw reply [relevance 61%]
* [GIT PULL] usercopy fix for v5.4-rc1
@ 2019-09-26 18:35 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2019-09-26 18:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Kees Cook, Matthew Wilcox, Randy Dunlap
Hi Linus,
Please pull this usercopy fix for v5.4-rc1. Randy found a corner case
(HIGHMEM, DEBUG_VIRTUAL, >512MB RAM) with hardened usercopy that went
unnoticed since v4.8. This adds HIGHMEM awareness to hardened usercopy,
and has been living in -next for a bit more than a week now.
Thanks!
-Kees
The following changes since commit 4d856f72c10ecb060868ed10ff1b1453943fc6c8:
Linux 5.3 (2019-09-15 14:19:32 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/usercopy-v5.4-rc1
for you to fetch changes up to 314eed30ede02fa925990f535652254b5bad6b65:
usercopy: Avoid HIGHMEM pfn warning (2019-09-17 15:20:17 -0700)
----------------------------------------------------------------
Fix hardened usercopy under CONFIG_DEBUG_VIRTUAL
----------------------------------------------------------------
Kees Cook (1):
usercopy: Avoid HIGHMEM pfn warning
mm/usercopy.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--
Kees Cook
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL] treewide conversion to sizeof_member() for v5.4-rc1
@ 2019-09-26 20:56 92% ` Kees Cook
2019-10-02 18:19 92% ` renaming FIELD_SIZEOF to sizeof_member (was Re: [GIT PULL] treewide conversion to sizeof_member() for v5.4-rc1) Kees Cook
0 siblings, 1 reply; 200+ results
From: Kees Cook @ 2019-09-26 20:56 UTC (permalink / raw)
To: Linus Torvalds, David S. Miller
Cc: Linux Kernel Mailing List, Pankaj Bharadiya, Joe Perches,
Alexey Dobriyan
On Thu, Sep 26, 2019 at 01:06:01PM -0700, Linus Torvalds wrote:
> (a) why didn't this use the already existing and well-named macro
> that nobody really had issues with?
That was suggested, but other folks wanted the more accurate "member"
instead of "field" since a treewide change was happening anyway:
https://www.openwall.com/lists/kernel-hardening/2019/07/02/2
At the end of the day, I really don't care -- I just want to have _one_
macro. :)
> (b) I see no sign of the networking people having been asked about
> their preferences.
Yeah, that's entirely true. Totally my mistake; it seemed like a trivial
enough change that I didn't want to bother too many people. But let's
fix that now... Dave, do you have any concerns about this change of
FIELD_SIZEOF() to sizeof_member() (or if it prevails, sizeof_field())?
--
Kees Cook
^ permalink raw reply [relevance 92%]
* renaming FIELD_SIZEOF to sizeof_member (was Re: [GIT PULL] treewide conversion to sizeof_member() for v5.4-rc1)
2019-09-26 20:56 92% ` Kees Cook
@ 2019-10-02 18:19 92% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2019-10-02 18:19 UTC (permalink / raw)
To: David Miller
Cc: linux-kernel, Linus Torvalds, Pankaj Bharadiya, Joe Perches,
Alexey Dobriyan, netdev
On Thu, Sep 26, 2019 at 01:56:55PM -0700, Kees Cook wrote:
> On Thu, Sep 26, 2019 at 01:06:01PM -0700, Linus Torvalds wrote:
> > (a) why didn't this use the already existing and well-named macro
> > that nobody really had issues with?
>
> That was suggested, but other folks wanted the more accurate "member"
> instead of "field" since a treewide change was happening anyway:
> https://www.openwall.com/lists/kernel-hardening/2019/07/02/2
>
> At the end of the day, I really don't care -- I just want to have _one_
> macro. :)
>
> > (b) I see no sign of the networking people having been asked about
> > their preferences.
>
> Yeah, that's entirely true. Totally my mistake; it seemed like a trivial
> enough change that I didn't want to bother too many people. But let's
> fix that now... Dave, do you have any concerns about this change of
> FIELD_SIZEOF() to sizeof_member() (or if it prevails, sizeof_field())?
David, can you weight in on this? Are you okay with a mass renaming of
FIELD_SIZEOF() to sizeof_member(), as the largest user of the old macro
is in networking?
Thanks!
--
Kees Cook
^ permalink raw reply [relevance 92%]
* [GIT PULL] seccomp updates for v5.5-rc1
@ 2019-11-26 16:25 79% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2019-11-26 16:25 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Alexei Starovoitov, David Abdurachmanov,
Paul Walmsley, Andy Lutomirski, Borislav Petkov, bpf,
Christian Brauner, Daniel Borkmann, kernel test robot,
linux-arm-kernel, linux-kselftest, linux-parisc, linux-s390,
linux-um, Martin KaFai Lau, netdev, Oleg Nesterov, Shuah Khan,
Song Liu, Thomas Gleixner, Tycho Andersen, Tyler Hicks,
Will Drewry, x86, Yonghong Song
Hi Linus,
Please pull these seccomp updates for v5.5-rc1. Mostly this is
implementing the new flag SECCOMP_USER_NOTIF_FLAG_CONTINUE, but there
are cleanups as well. Most notably, the secure_computing() prototype
has changed (to remove an unused argument), but this has happened at the
same time as riscv adding seccomp support, so the cleanest merge order
would be to merge riscv first, then seccomp with the following patch for
riscv to handle the change from "seccomp: simplify secure_computing()":
diff --git a/arch/riscv/kernel/ptrace.c b/arch/riscv/kernel/ptrace.c
index 0f84628b9385..407464201b91 100644
--- a/arch/riscv/kernel/ptrace.c
+++ b/arch/riscv/kernel/ptrace.c
@@ -159,7 +159,7 @@ __visible void do_syscall_trace_enter(struct pt_regs *regs)
* If this fails we might have return value in a0 from seccomp
* (via SECCOMP_RET_ERRNO/TRACE).
*/
- if (secure_computing(NULL) == -1) {
+ if (secure_computing() == -1) {
syscall_set_nr(current, regs, -1);
return;
}
Thanks!
-Kees
The following changes since commit da0c9ea146cbe92b832f1b0f694840ea8eb33cce:
Linux 5.4-rc2 (2019-10-06 14:27:30 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-v5.5-rc1
for you to fetch changes up to 23b2c96fad21886c53f5e1a4ffedd45ddd2e85ba:
seccomp: rework define for SECCOMP_USER_NOTIF_FLAG_CONTINUE (2019-10-28 12:29:46 -0700)
----------------------------------------------------------------
seccomp updates for v5.5
- implement SECCOMP_USER_NOTIF_FLAG_CONTINUE (Christian Brauner)
- fixes to selftests (Christian Brauner)
- remove secure_computing() argument (Christian Brauner)
----------------------------------------------------------------
Christian Brauner (6):
seccomp: avoid overflow in implicit constant conversion
seccomp: add SECCOMP_USER_NOTIF_FLAG_CONTINUE
seccomp: test SECCOMP_USER_NOTIF_FLAG_CONTINUE
seccomp: simplify secure_computing()
seccomp: fix SECCOMP_USER_NOTIF_FLAG_CONTINUE test
seccomp: rework define for SECCOMP_USER_NOTIF_FLAG_CONTINUE
arch/arm/kernel/ptrace.c | 2 +-
arch/arm64/kernel/ptrace.c | 2 +-
arch/parisc/kernel/ptrace.c | 2 +-
arch/s390/kernel/ptrace.c | 2 +-
arch/um/kernel/skas/syscall.c | 2 +-
arch/x86/entry/vsyscall/vsyscall_64.c | 2 +-
include/linux/seccomp.h | 6 +-
include/uapi/linux/seccomp.h | 29 +++++++
kernel/seccomp.c | 28 +++++--
tools/testing/selftests/seccomp/seccomp_bpf.c | 110 +++++++++++++++++++++++++-
10 files changed, 169 insertions(+), 16 deletions(-)
--
Kees Cook
^ permalink raw reply related [relevance 79%]
* [GIT PULL] pstore update for v5.5-rc1
@ 2019-11-26 16:29 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2019-11-26 16:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Ben Dooks
Hi Linus,
Please pull this tiny pstore update for v5.5-rc1. It contains a single
fix for a missing "static". :)
Thanks!
-Kees
The following changes since commit da0c9ea146cbe92b832f1b0f694840ea8eb33cce:
Linux 5.4-rc2 (2019-10-06 14:27:30 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/pstore-v5.5-rc1
for you to fetch changes up to 8d82cee2f8aa8b9bc806907ecd9e1494c6e8526b:
pstore: Make pstore_choose_compression() static (2019-10-29 09:43:03 -0700)
----------------------------------------------------------------
pstore bug fix
- add missing "static" (Ben Dooks)
----------------------------------------------------------------
Ben Dooks (Codethink) (1):
pstore: Make pstore_choose_compression() static
fs/pstore/platform.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
Kees Cook
^ permalink raw reply [relevance 92%]
* [GIT PULL] treewide conversion to sizeof_member() for v5.5-rc1
@ 2019-12-07 19:48 58% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2019-12-07 19:48 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, David Miller, Pankaj Bharadiya, Alexey Dobriyan,
Joe Perches
Hi Linus,
Please pull this mostly mechanical treewide conversion to the single and
more accurately named sizeof_member() macro for the end of v5.5-rc1. This
replaces 3 macros of the same behavior (FIELD_SIZEOF(), SIZEOF_FIELD(),
and sizeof_field()). The last patch in the series has a script in the
commit log to do the conversion, if you want to compare the results.
(Since v5.4-rc2, there are 4 new users of the old macros, if you care
to refresh the commit.)
I believe the concerns from your feedback on the v5.4 pull request[1]
have been addressed with an Ack from Dave Miller[2], and clarification
of the naming[3]. The series has lived in linux-next for the entire
development cycle and had only 1 trivial conflict[4].
As there are a few new users of the old macros in your tree and in
linux-next (targeting the next merge window), I will clean up those final
users during this coming development cycle and send the final old macro
removal patch[5] at that time.
Thanks!
-Kees
[1] https://lore.kernel.org/lkml/CAHk-=wg8+eNK+SK1Ekqm0qNQHVM6e6YOdZx3yhsX6Ajo3gEupg@mail.gmail.com/
[2] https://lore.kernel.org/lkml/20191002.132121.402975401040540710.davem@davemloft.net/
[3] https://lore.kernel.org/lkml/20190927065700.GA2215@avx2/
[4] https://lore.kernel.org/lkml/20191106160331.016b2521@canb.auug.org.au/
[5] https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=kspp/sizeof_member/slow-full&id=4aa9c5de448cdb804c83f285d63a93c249ba6fa5
The following changes since commit da0c9ea146cbe92b832f1b0f694840ea8eb33cce:
Linux 5.4-rc2 (2019-10-06 14:27:30 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/sizeof_member-v5.5-rc1
for you to fetch changes up to ec2f877856e0af3889940e00b160f7f20f8d774f:
treewide: Use sizeof_member() macro (2019-10-29 15:35:27 -0700)
----------------------------------------------------------------
treewide conversion to new sizeof_member() macro
----------------------------------------------------------------
Pankaj Bharadiya (3):
MIPS: OCTEON: Replace SIZEOF_FIELD() macro
linux/stddef.h: Add sizeof_member() macro
treewide: Use sizeof_member() macro
Documentation/process/coding-style.rst | 2 +-
.../translations/it_IT/process/coding-style.rst | 2 +-
.../translations/zh_CN/process/coding-style.rst | 2 +-
arch/arc/kernel/unwind.c | 6 +-
arch/arm64/include/asm/processor.h | 10 +-
arch/mips/cavium-octeon/executive/cvmx-bootmem.c | 9 +-
arch/powerpc/net/bpf_jit32.h | 4 +-
arch/powerpc/net/bpf_jit_comp.c | 16 +--
arch/sparc/net/bpf_jit_comp_32.c | 8 +-
arch/x86/kernel/fpu/xstate.c | 2 +-
block/blk-core.c | 4 +-
crypto/adiantum.c | 4 +-
crypto/essiv.c | 2 +-
drivers/firmware/efi/efi.c | 2 +-
drivers/gpu/drm/i915/gvt/scheduler.c | 2 +-
drivers/infiniband/hw/efa/efa_verbs.c | 2 +-
drivers/infiniband/hw/hfi1/sdma.c | 2 +-
drivers/infiniband/hw/hfi1/verbs.h | 4 +-
drivers/infiniband/ulp/opa_vnic/opa_vnic_ethtool.c | 2 +-
drivers/input/keyboard/applespi.c | 2 +-
drivers/md/raid5-ppl.c | 2 +-
drivers/media/platform/omap3isp/isppreview.c | 24 ++--
drivers/net/ethernet/amd/xgbe/xgbe-ethtool.c | 4 +-
.../net/ethernet/cavium/liquidio/octeon_console.c | 16 +--
drivers/net/ethernet/emulex/benet/be_ethtool.c | 2 +-
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 2 +-
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c | 2 +-
drivers/net/ethernet/huawei/hinic/hinic_ethtool.c | 8 +-
drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c | 2 +-
drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 2 +-
drivers/net/ethernet/intel/i40e/i40e_lan_hmc.c | 2 +-
drivers/net/ethernet/intel/iavf/iavf_ethtool.c | 2 +-
drivers/net/ethernet/intel/ice/ice_ethtool.c | 10 +-
drivers/net/ethernet/intel/ice/ice_lan_tx_rx.h | 2 +-
drivers/net/ethernet/intel/igb/igb_ethtool.c | 4 +-
drivers/net/ethernet/intel/igc/igc_ethtool.c | 4 +-
drivers/net/ethernet/intel/ixgb/ixgb_ethtool.c | 4 +-
drivers/net/ethernet/intel/ixgbevf/ethtool.c | 4 +-
drivers/net/ethernet/marvell/mv643xx_eth.c | 4 +-
drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 2 +-
.../net/ethernet/mellanox/mlx5/core/fpga/ipsec.c | 6 +-
drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 4 +-
drivers/net/ethernet/mellanox/mlxsw/spectrum_fid.c | 4 +-
drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.c | 2 +-
drivers/net/ethernet/netronome/nfp/bpf/jit.c | 10 +-
drivers/net/ethernet/netronome/nfp/bpf/main.c | 2 +-
drivers/net/ethernet/netronome/nfp/bpf/offload.c | 2 +-
drivers/net/ethernet/netronome/nfp/flower/main.h | 2 +-
.../ethernet/oki-semi/pch_gbe/pch_gbe_ethtool.c | 2 +-
drivers/net/ethernet/qlogic/qede/qede.h | 2 +-
.../net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c | 2 +-
drivers/net/ethernet/samsung/sxgbe/sxgbe_ethtool.c | 2 +-
.../net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 4 +-
drivers/net/ethernet/ti/cpsw_ethtool.c | 6 +-
drivers/net/ethernet/ti/netcp_ethss.c | 32 ++---
drivers/net/fjes/fjes_ethtool.c | 2 +-
drivers/net/geneve.c | 2 +-
drivers/net/hyperv/netvsc_drv.c | 2 +-
drivers/net/usb/sierra_net.c | 2 +-
drivers/net/usb/usbnet.c | 2 +-
drivers/net/vxlan.c | 4 +-
drivers/net/wireless/marvell/libertas/debugfs.c | 2 +-
drivers/net/wireless/marvell/mwifiex/util.h | 4 +-
drivers/s390/net/qeth_core_main.c | 2 +-
drivers/s390/net/qeth_core_mpc.h | 10 +-
drivers/scsi/aacraid/aachba.c | 4 +-
drivers/scsi/be2iscsi/be_cmds.h | 2 +-
drivers/scsi/cxgbi/libcxgbi.c | 2 +-
drivers/scsi/smartpqi/smartpqi_init.c | 6 +-
drivers/staging/qlge/qlge_ethtool.c | 2 +-
drivers/target/iscsi/cxgbit/cxgbit_main.c | 2 +-
drivers/usb/atm/usbatm.c | 2 +-
drivers/usb/gadget/function/f_fs.c | 2 +-
fs/befs/linuxvfs.c | 2 +-
fs/crypto/keyring.c | 2 +-
fs/ext2/super.c | 2 +-
fs/ext4/super.c | 2 +-
fs/freevxfs/vxfs_super.c | 2 +-
fs/fuse/virtio_fs.c | 2 +-
fs/orangefs/super.c | 2 +-
fs/ufs/super.c | 2 +-
fs/verity/enable.c | 2 +-
include/linux/filter.h | 12 +-
include/linux/kvm_host.h | 2 +-
include/linux/phy_led_triggers.h | 2 +-
include/linux/slab.h | 2 +-
include/linux/stddef.h | 13 +-
include/net/garp.h | 2 +-
include/net/ip_tunnels.h | 6 +-
include/net/mrp.h | 2 +-
include/net/netfilter/nf_conntrack_helper.h | 2 +-
include/net/netfilter/nf_tables_core.h | 2 +-
include/net/sock.h | 2 +-
ipc/util.c | 2 +-
kernel/bpf/cgroup.c | 2 +-
kernel/bpf/local_storage.c | 4 +-
kernel/fork.c | 2 +-
kernel/signal.c | 12 +-
kernel/utsname.c | 2 +-
net/802/mrp.c | 6 +-
net/batman-adv/main.c | 2 +-
net/bridge/br.c | 2 +-
net/caif/caif_socket.c | 2 +-
net/core/dev.c | 2 +-
net/core/filter.c | 140 ++++++++++-----------
net/core/flow_dissector.c | 10 +-
net/core/skbuff.c | 2 +-
net/core/xdp.c | 4 +-
net/dccp/proto.c | 2 +-
net/ipv4/ip_gre.c | 4 +-
net/ipv4/ip_vti.c | 4 +-
net/ipv4/raw.c | 2 +-
net/ipv4/tcp.c | 2 +-
net/ipv6/ip6_gre.c | 4 +-
net/ipv6/raw.c | 2 +-
net/iucv/af_iucv.c | 2 +-
net/netfilter/nf_tables_api.c | 4 +-
net/netfilter/nfnetlink_cthelper.c | 2 +-
net/netfilter/nft_ct.c | 12 +-
net/netfilter/nft_masq.c | 2 +-
net/netfilter/nft_nat.c | 6 +-
net/netfilter/nft_redir.c | 2 +-
net/netfilter/nft_tproxy.c | 4 +-
net/netfilter/xt_RATEEST.c | 2 +-
net/netlink/af_netlink.c | 2 +-
net/openvswitch/datapath.c | 2 +-
net/openvswitch/flow.h | 4 +-
net/rxrpc/af_rxrpc.c | 2 +-
net/sched/act_ct.c | 4 +-
net/sched/cls_flower.c | 2 +-
net/sctp/socket.c | 4 +-
net/unix/af_unix.c | 2 +-
security/integrity/ima/ima_policy.c | 4 +-
sound/soc/codecs/hdmi-codec.c | 2 +-
tools/testing/selftests/bpf/bpf_util.h | 6 +-
virt/kvm/kvm_main.c | 2 +-
136 files changed, 340 insertions(+), 336 deletions(-)
--
Kees Cook
^ permalink raw reply [relevance 58%]
* [GIT PULL] treewide conversion to sizeof_field() for v5.5-rc2
@ 2019-12-09 19:05 63% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2019-12-09 19:05 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, David Miller, Pankaj Bharadiya, Alexey Dobriyan,
Joe Perches
Hi Linus,
Third time's the charm? Please pull this mostly mechanical treewide
conversion from FIELD_SIZEOF() to sizeof_field(). This avoids the
redundancy of having 2 macros (actually 3) doing the same thing, and
consolidates on sizeof_field(). While "field" is not an accurate name,
it is the common name used in the kernel, and doesn't result in any
unintended innuendo.
As there are still users of FIELD_SIZEOF() in -next, I will clean up
those during this coming development cycle and send the final old macro
removal patch at that time. (Unless you'd rather have it be "completed"
in your tree immediately?)
Thanks!
-Kees
v2: https://lore.kernel.org/lkml/201912071144.768E249A4F@keescook/
v1: https://lore.kernel.org/lkml/201909261026.6E3381876C@keescook/
The following changes since commit e42617b825f8073569da76dc4510bfa019b1c35a:
Linux 5.5-rc1 (2019-12-08 14:57:55 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/sizeof_field-v5.5-rc2
for you to fetch changes up to c593642c8be046915ca3a4a300243a68077cd207:
treewide: Use sizeof_field() macro (2019-12-09 10:36:44 -0800)
----------------------------------------------------------------
treewide conversion from FIELD_SIZEOF() to sizeof_field()
----------------------------------------------------------------
Pankaj Bharadiya (2):
MIPS: OCTEON: Replace SIZEOF_FIELD() macro
treewide: Use sizeof_field() macro
Documentation/process/coding-style.rst | 2 +-
.../translations/it_IT/process/coding-style.rst | 2 +-
.../translations/zh_CN/process/coding-style.rst | 2 +-
arch/arc/kernel/unwind.c | 6 +-
arch/mips/cavium-octeon/executive/cvmx-bootmem.c | 9 +-
arch/powerpc/net/bpf_jit32.h | 4 +-
arch/powerpc/net/bpf_jit_comp.c | 16 +--
arch/sparc/net/bpf_jit_comp_32.c | 8 +-
arch/x86/kernel/fpu/xstate.c | 2 +-
block/blk-core.c | 4 +-
crypto/adiantum.c | 4 +-
crypto/essiv.c | 2 +-
drivers/firmware/efi/efi.c | 2 +-
drivers/infiniband/hw/efa/efa_verbs.c | 2 +-
drivers/infiniband/hw/hfi1/sdma.c | 2 +-
drivers/infiniband/hw/hfi1/verbs.h | 4 +-
drivers/infiniband/ulp/opa_vnic/opa_vnic_ethtool.c | 2 +-
drivers/md/raid5-ppl.c | 2 +-
drivers/media/platform/omap3isp/isppreview.c | 24 ++--
drivers/media/v4l2-core/v4l2-ioctl.c | 2 +-
drivers/net/ethernet/amd/xgbe/xgbe-ethtool.c | 4 +-
.../net/ethernet/cavium/liquidio/octeon_console.c | 16 +--
drivers/net/ethernet/emulex/benet/be_ethtool.c | 2 +-
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 2 +-
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c | 2 +-
drivers/net/ethernet/huawei/hinic/hinic_ethtool.c | 8 +-
drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c | 2 +-
drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 2 +-
drivers/net/ethernet/intel/i40e/i40e_lan_hmc.c | 2 +-
drivers/net/ethernet/intel/iavf/iavf_ethtool.c | 2 +-
drivers/net/ethernet/intel/ice/ice_ethtool.c | 10 +-
drivers/net/ethernet/intel/ice/ice_lan_tx_rx.h | 2 +-
drivers/net/ethernet/intel/igb/igb_ethtool.c | 4 +-
drivers/net/ethernet/intel/igc/igc_ethtool.c | 4 +-
drivers/net/ethernet/intel/ixgb/ixgb_ethtool.c | 4 +-
drivers/net/ethernet/intel/ixgbevf/ethtool.c | 4 +-
drivers/net/ethernet/marvell/mv643xx_eth.c | 4 +-
drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 2 +-
.../net/ethernet/mellanox/mlx5/core/fpga/ipsec.c | 6 +-
drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 4 +-
drivers/net/ethernet/netronome/nfp/bpf/jit.c | 10 +-
drivers/net/ethernet/netronome/nfp/bpf/main.c | 2 +-
drivers/net/ethernet/netronome/nfp/bpf/offload.c | 2 +-
drivers/net/ethernet/netronome/nfp/flower/main.h | 2 +-
.../ethernet/oki-semi/pch_gbe/pch_gbe_ethtool.c | 2 +-
drivers/net/ethernet/qlogic/qede/qede.h | 2 +-
.../net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c | 2 +-
drivers/net/ethernet/realtek/r8169_firmware.c | 2 +-
drivers/net/ethernet/samsung/sxgbe/sxgbe_ethtool.c | 2 +-
.../net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 4 +-
drivers/net/ethernet/ti/cpsw_ethtool.c | 6 +-
drivers/net/ethernet/ti/netcp_ethss.c | 32 ++---
drivers/net/fjes/fjes_ethtool.c | 2 +-
drivers/net/geneve.c | 2 +-
drivers/net/hyperv/netvsc_drv.c | 2 +-
drivers/net/usb/sierra_net.c | 2 +-
drivers/net/usb/usbnet.c | 2 +-
drivers/net/vxlan.c | 4 +-
drivers/net/wireless/marvell/libertas/debugfs.c | 2 +-
drivers/net/wireless/marvell/mwifiex/util.h | 4 +-
drivers/s390/net/qeth_core_main.c | 2 +-
drivers/s390/net/qeth_core_mpc.h | 10 +-
drivers/scsi/aacraid/aachba.c | 4 +-
drivers/scsi/be2iscsi/be_cmds.h | 2 +-
drivers/scsi/cxgbi/libcxgbi.c | 2 +-
drivers/scsi/smartpqi/smartpqi_init.c | 6 +-
drivers/staging/qlge/qlge_ethtool.c | 2 +-
drivers/staging/wfx/data_tx.c | 2 +-
drivers/target/iscsi/cxgbit/cxgbit_main.c | 2 +-
drivers/usb/atm/usbatm.c | 2 +-
drivers/usb/gadget/function/f_fs.c | 2 +-
fs/crypto/keyring.c | 2 +-
fs/verity/enable.c | 2 +-
include/linux/filter.h | 12 +-
include/linux/kvm_host.h | 2 +-
include/linux/phy_led_triggers.h | 2 +-
include/net/garp.h | 2 +-
include/net/ip_tunnels.h | 6 +-
include/net/mrp.h | 2 +-
include/net/netfilter/nf_conntrack_helper.h | 2 +-
include/net/netfilter/nf_tables_core.h | 2 +-
include/net/sock.h | 2 +-
ipc/util.c | 2 +-
kernel/bpf/cgroup.c | 2 +-
kernel/bpf/local_storage.c | 4 +-
net/802/mrp.c | 6 +-
net/batman-adv/main.c | 2 +-
net/bpf/test_run.c | 8 +-
net/bridge/br.c | 2 +-
net/core/dev.c | 2 +-
net/core/filter.c | 140 ++++++++++-----------
net/core/flow_dissector.c | 10 +-
net/core/xdp.c | 4 +-
net/dccp/proto.c | 2 +-
net/ipv4/ip_gre.c | 4 +-
net/ipv4/ip_vti.c | 4 +-
net/ipv4/tcp.c | 2 +-
net/ipv6/ip6_gre.c | 4 +-
net/iucv/af_iucv.c | 2 +-
net/netfilter/nf_tables_api.c | 4 +-
net/netfilter/nfnetlink_cthelper.c | 2 +-
net/netfilter/nft_ct.c | 12 +-
net/netfilter/nft_masq.c | 2 +-
net/netfilter/nft_nat.c | 6 +-
net/netfilter/nft_redir.c | 2 +-
net/netfilter/nft_tproxy.c | 4 +-
net/netfilter/xt_RATEEST.c | 2 +-
net/netlink/af_netlink.c | 2 +-
net/openvswitch/datapath.c | 2 +-
net/openvswitch/flow.h | 4 +-
net/rxrpc/af_rxrpc.c | 2 +-
net/sched/act_ct.c | 4 +-
net/sched/cls_flower.c | 2 +-
net/unix/af_unix.c | 2 +-
security/integrity/ima/ima_policy.c | 4 +-
sound/soc/codecs/hdmi-codec.c | 2 +-
116 files changed, 299 insertions(+), 306 deletions(-)
--
Kees Cook
^ permalink raw reply [relevance 63%]
* [GIT PULL] pstore fixes for v5.5-rc5
@ 2020-01-02 20:55 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2020-01-02 20:55 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Aleksandr Yashkin, Ariel Gilman, Navid Emamdoost,
Nikolay Merinov
Hi Linus,
Please pull these two pstore fixes for v5.5-rc5.
Thanks!
-Kees
The following changes since commit d1eef1c619749b2a57e514a3fa67d9a516ffa919:
Linux 5.5-rc2 (2019-12-15 15:16:08 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/pstore-v5.5-rc5
for you to fetch changes up to 9e5f1c19800b808a37fb9815a26d382132c26c3d:
pstore/ram: Write new dumps to start of recycled zones (2020-01-02 12:30:50 -0800)
----------------------------------------------------------------
pstore bug fixes
- always reset circular buffer state when writing new dump (Aleksandr Yashkin)
- fix rare error-path memory leak (Kees Cook)
----------------------------------------------------------------
Aleksandr Yashkin (1):
pstore/ram: Write new dumps to start of recycled zones
Kees Cook (1):
pstore/ram: Fix error-path memory leak in persistent_ram_new() callers
fs/pstore/ram.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
--
Kees Cook
^ permalink raw reply [relevance 92%]
* [GIT PULL] seccomp fixes for v5.5-rc5
@ 2020-01-02 21:28 91% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2020-01-02 21:28 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Aleksa Sarai, Christian Brauner, Sargun Dhillon,
Tycho Andersen
Hi Linus,
Please pull these seccomp fixes for v5.5-rc5. The bulk of this is fixing
the surrounding samples and selftests so that seccomp can correctly
validate the seccomp_notify_ioctl buffer as being initially zeroed.
Thanks!
-Kees
The following changes since commit fd6988496e79a6a4bdb514a4655d2920209eb85d:
Linux 5.5-rc4 (2019-12-29 15:29:16 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-v5.5-rc5
for you to fetch changes up to e4ab5ccc357b978999328fadae164e098c26fa40:
selftests/seccomp: Catch garbage on SECCOMP_IOCTL_NOTIF_RECV (2020-01-02 13:15:45 -0800)
----------------------------------------------------------------
Fixes for seccomp_notify_ioctl uapi sanity
- Fix samples and selftests to zero passed-in buffer (Sargun Dhillon)
- Enforce zeroed buffer checking (Sargun Dhillon)
- Verify buffer sanity check in selftest (Sargun Dhillon)
----------------------------------------------------------------
Sargun Dhillon (4):
samples/seccomp: Zero out members based on seccomp_notif_sizes
selftests/seccomp: Zero out seccomp_notif
seccomp: Check that seccomp_notif is zeroed out by the user
selftests/seccomp: Catch garbage on SECCOMP_IOCTL_NOTIF_RECV
kernel/seccomp.c | 7 +++++++
samples/seccomp/user-trap.c | 4 ++--
tools/testing/selftests/seccomp/seccomp_bpf.c | 15 ++++++++++++++-
3 files changed, 23 insertions(+), 3 deletions(-)
--
Kees Cook
^ permalink raw reply [relevance 91%]
* [GIT PULL] gcc-plugins fix for v5.5-rc5
@ 2020-01-02 21:38 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2020-01-02 21:38 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Ard Biesheuvel, Arnd Bergmann, Kees Cook, Masahiro Yamada
Hi Linus,
Please pull this gcc-plugins fix for v5.5-rc5. This change will make
some builder's lives easier again for build configuration testing
with/without gcc-plugins. Masahiro asked that it go via my tree, so here
it is! :)
Thanks!
-Kees
The following changes since commit fd6988496e79a6a4bdb514a4655d2920209eb85d:
Linux 5.5-rc4 (2019-12-29 15:29:16 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/gcc-plugins-v5.5-rc5
for you to fetch changes up to a5b0dc5a46c221725c43bd9b01570239a4cd78b1:
gcc-plugins: make it possible to disable CONFIG_GCC_PLUGINS again (2020-01-02 13:30:14 -0800)
----------------------------------------------------------------
gcc-plugins build flexibility fix
- Allow builds to disable plugins even when plugins available (Arnd Bergmann)
----------------------------------------------------------------
Arnd Bergmann (1):
gcc-plugins: make it possible to disable CONFIG_GCC_PLUGINS again
scripts/gcc-plugins/Kconfig | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
--
Kees Cook
^ permalink raw reply [relevance 92%]
* [GIT PULL] FIELD_SIZEOF() removal for v5.5-rc5
@ 2020-01-02 21:48 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2020-01-02 21:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel
Hi Linus,
Please pull this last change for the sizeof_field() conversion for
v5.5-rc5. With all FIELD_SIZEOF() users now gone from both your tree and
linux-next, we can remove it and the conversion is done! :)
Thanks!
-Kees
The following changes since commit fd6988496e79a6a4bdb514a4655d2920209eb85d:
Linux 5.5-rc4 (2019-12-29 15:29:16 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/sizeof_field-v5.5-rc5
for you to fetch changes up to 1f07dcc459d5f2c639f185f6e94829a0c79f2b4c:
kernel.h: Remove unused FIELD_SIZEOF() (2019-12-30 12:01:56 -0800)
----------------------------------------------------------------
sizeof_field conversion
- Remove now unused FIELD_SIZEOF() macro (Kees Cook)
----------------------------------------------------------------
Kees Cook (1):
kernel.h: Remove unused FIELD_SIZEOF()
include/linux/kernel.h | 9 ---------
1 file changed, 9 deletions(-)
--
Kees Cook
^ permalink raw reply [relevance 92%]
* [GIT PULL] pstore fix for v5.5-rc6
@ 2020-01-10 4:46 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2020-01-10 4:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Cengiz Can
Hi Linus,
Please pull this pstore fix for v5.5-rc6. Cengiz Can forwarded a Coverity
report about more problems with a rare pstore initialization error path,
so the allocation lifetime was rearranged to avoid needing to share the
kfree() responsibilities between caller and callee.
Thanks!
-Kees
The following changes since commit 9e5f1c19800b808a37fb9815a26d382132c26c3d:
pstore/ram: Write new dumps to start of recycled zones (2020-01-02 12:30:50 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/pstore-v5.5-rc6
for you to fetch changes up to e163fdb3f7f8c62dccf194f3f37a7bcb3c333aa8:
pstore/ram: Regularize prz label allocation lifetime (2020-01-08 17:05:45 -0800)
----------------------------------------------------------------
pstore fix for rare error path
- Fix label allocation lifetime/visibility to avoid further mistakes
----------------------------------------------------------------
Kees Cook (1):
pstore/ram: Regularize prz label allocation lifetime
fs/pstore/ram.c | 4 ++--
fs/pstore/ram_core.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
--
Kees Cook
^ permalink raw reply [relevance 92%]
* [GIT PULL] READ_IMPLIES_EXEC cleanup for -tip next
@ 2020-03-03 4:25 89% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2020-03-03 4:25 UTC (permalink / raw)
To: Thomas Gleixner
Cc: linux-kernel, Catalin Marinas, Hector Marco-Gisbert, Jason Gunthorpe
Hi Thomas,
Please pull these READ_IMPLIES_EXEC cleanups. They've got Acks, and have
been sitting without further commented since v4:
https://lore.kernel.org/lkml/20200225051307.6401-1-keescook@chromium.org/#r
Catalin specifically asked me during Plumbers if I could get this series
refreshed and finalized, so here we are! :) I'd wanted to keep these all
together so per-arch RIE special cases were changed at the same time.
Thanks!
-Kees
The following changes since commit 11a48a5a18c63fd7621bb050228cebf13566e4d8:
Linux 5.6-rc2 (2020-02-16 13:16:59 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/rie-cleanup-next
for you to fetch changes up to 631551ed971466e4a7ea0b6b11a4ddf2b80513d3:
arm64, elf: Disable automatic READ_IMPLIES_EXEC for 64-bit address spaces (2020-02-24 21:00:51 -0800)
----------------------------------------------------------------
READ_IMPLIES_EXEC cleanups
- Fix READ_IMPLIES_EXEC across x86, arm64, and arm
----------------------------------------------------------------
Kees Cook (6):
x86/elf: Add table to document READ_IMPLIES_EXEC
x86/elf: Split READ_IMPLIES_EXEC from executable GNU_STACK
x86/elf: Disable automatic READ_IMPLIES_EXEC for 64-bit address spaces
arm32/64, elf: Add tables to document READ_IMPLIES_EXEC
arm32/64, elf: Split READ_IMPLIES_EXEC from executable GNU_STACK
arm64, elf: Disable automatic READ_IMPLIES_EXEC for 64-bit address spaces
arch/arm/kernel/elf.c | 27 +++++++++++++++++++++++----
arch/arm64/include/asm/elf.h | 23 ++++++++++++++++++++++-
arch/x86/include/asm/elf.h | 22 +++++++++++++++++++++-
fs/compat_binfmt_elf.c | 5 +++++
4 files changed, 71 insertions(+), 6 deletions(-)
--
Kees Cook
^ permalink raw reply [relevance 89%]
* [GIT PULL] seccomp updates for v5.7-rc1
@ 2020-03-30 4:16 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2020-03-30 4:16 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Kees Cook, Matthew Denton, Sven Schnelle, Tycho Andersen
Hi Linus,
Please pull these couple of seccomp updates for v5.7-rc1. They're both
mostly bug fixes that I wanted to have sit in linux-next for a while.
That's done now, so here they are for v5.7.
Thanks!
-Kees
The following changes since commit 11a48a5a18c63fd7621bb050228cebf13566e4d8:
Linux 5.6-rc2 (2020-02-16 13:16:59 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-v5.7-rc1
for you to fetch changes up to 3db81afd99494a33f1c3839103f0429c8f30cb9d:
seccomp: Add missing compat_ioctl for notify (2020-03-29 21:10:51 -0700)
----------------------------------------------------------------
updates for seccomp
- allow TSYNC and USER_NOTIF together (Tycho Andersen)
- Add missing compat_ioctl for notify (Sven Schnelle)
----------------------------------------------------------------
Sven Schnelle (1):
seccomp: Add missing compat_ioctl for notify
Tycho Andersen (1):
seccomp: allow TSYNC and USER_NOTIF together
include/linux/seccomp.h | 3 +-
include/uapi/linux/seccomp.h | 1 +
kernel/seccomp.c | 15 ++++--
tools/testing/selftests/seccomp/seccomp_bpf.c | 74 ++++++++++++++++++++++++++-
4 files changed, 87 insertions(+), 6 deletions(-)
--
Kees Cook
^ permalink raw reply [relevance 92%]
* [GIT PULL] pstore updates for v5.7-rc1
@ 2020-03-30 4:21 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2020-03-30 4:21 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, chenqiwu, Gustavo A. R. Silva, Kees Cook, Vasily Averin
Hi Linus,
Please pull these pstore updates for v5.7-rc1. These mostly some minor
cleanups and a bug fix for an ftrace corner case.
Thanks!
-Kees
The following changes since commit 11a48a5a18c63fd7621bb050228cebf13566e4d8:
Linux 5.6-rc2 (2020-02-16 13:16:59 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/pstore-v5.7-rc1
for you to fetch changes up to 8128d3aac0ee3420ede34950c9c0ef9ee118bec9:
pstore/ram: Replace zero-length array with flexible-array member (2020-03-09 14:45:40 -0700)
----------------------------------------------------------------
pstore updates
- Improve failure paths (chenqiwu)
- Fix ftrace position index (Vasily Averin)
- Use proper flexible-array member (Gustavo A. R. Silva)
----------------------------------------------------------------
Gustavo A. R. Silva (1):
pstore/ram: Replace zero-length array with flexible-array member
Vasily Averin (1):
pstore: pstore_ftrace_seq_next should increase position index
chenqiwu (2):
pstore/platform: fix potential mem leak if pstore_init_fs failed
pstore/ram: remove unnecessary ramoops_unregister_dummy()
fs/pstore/inode.c | 5 ++++-
fs/pstore/platform.c | 4 ++--
fs/pstore/ram.c | 1 -
fs/pstore/ram_core.c | 2 +-
4 files changed, 7 insertions(+), 5 deletions(-)
--
Kees Cook
^ permalink raw reply [relevance 92%]
* [GIT PULL] gcc-plugins fixes for v5.7-rc5
@ 2020-05-04 17:46 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2020-05-04 17:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Frédéric Pierret
Hi Linus,
Please pull these gcc-plugins fixes for v5.7-rc5. These are some more
clean-ups for using the plugins under GCC 10.
Thanks!
-Kees
The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:
Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/gcc-plugins-v5.7-rc5
for you to fetch changes up to c7527373fe28f97d8a196ab562db5589be0d34b9:
gcc-common.h: Update for GCC 10 (2020-04-13 10:19:20 -0700)
----------------------------------------------------------------
GCC 10 fixes for gcc-plugins
- Adjust caller of cgraph_create_edge for GCC 10 argument usage
- Update common headers to build under GCC 10 (Frédéric Pierret)
----------------------------------------------------------------
Frédéric Pierret (fepitre) (1):
gcc-common.h: Update for GCC 10
Kees Cook (1):
gcc-plugins/stackleak: Avoid assignment for unused macro argument
scripts/gcc-plugins/Makefile | 1 +
scripts/gcc-plugins/gcc-common.h | 4 ++++
scripts/gcc-plugins/stackleak_plugin.c | 5 ++---
3 files changed, 7 insertions(+), 3 deletions(-)
--
Kees Cook
^ permalink raw reply [relevance 92%]
* [GIT PULL] pstore updates for v5.8-rc1
@ 2020-06-01 2:57 71% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2020-06-01 2:57 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Colin Ian King, Luis Henriques, Michael Ellerman,
Pavel Tatashin, Petr Mladek, Sergey Senozhatsky, WeiXiong Liao
Hi Linus,
Please pull these pstore updates for v5.8-rc1. This is a pretty big set
of changes (relative to past pstore pulls), but they've lived in -next
for a while. The biggest change here is the ability to support a block
device as a pstore backend, which has been desired for a while. A lot of
additional fixes and refactorings are also included, mostly in support
of the new features.
Thanks!
-Kees
The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:
Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/pstore-v5.8-rc1
for you to fetch changes up to 78c08247b9d3e03192f8b359aa079024e805a948:
mtd: Support kmsg dumper based on pstore/blk (2020-05-31 19:49:01 -0700)
----------------------------------------------------------------
Fixes and new features for pstore
- refactor pstore locking for safer module unloading (Kees Cook)
- remove orphaned records from pstorefs when backend unloaded (Kees Cook)
- refactor dump_oops parameter into max_reason (Pavel Tatashin)
- introduce pstore/zone for common code for contiguous storage (WeiXiong Liao)
- introduce pstore/blk for block device backend (WeiXiong Liao)
- introduce mtd backend (WeiXiong Liao)
----------------------------------------------------------------
Kees Cook (22):
pstore: Drop useless try_module_get() for backend
pstore: Rename "pstore_lock" to "psinfo_lock"
pstore: Convert "psinfo" locking to mutex
pstore: Rename "allpstore" to "records_list"
pstore: Convert "records_list" locking to mutex
pstore: Add proper unregister lock checking
pstore: Refactor pstorefs record list removal
pstore: Add locking around superblock changes
pstore: Do not leave timer disabled for next backend
pstore: Remove filesystem records when backend is unregistered
pstore: Make sure console capturing will restart
pstore/platform: Switch pstore_info::name to const
pstore/platform: Use backend name for console registration
pstore/platform: Move module params after declarations
pstore/ram: Adjust module param permissions to reflect reality
pstore/ram: Refactor DT size parsing
pstore/ram: Refactor ftrace buffer merging
pstore/ftrace: Provide ftrace log merging routine
printk: Collapse shutdown types into a single dump reason
printk: Introduce kmsg_dump_reason_str()
pstore/ram: Introduce max_reason and convert dump_oops
pstore/blk: Introduce "best_effort" mode
Pavel Tatashin (3):
printk: honor the max_reason field in kmsg_dumper
pstore/platform: Pass max_reason to kmesg dump
ramoops: Add "max-reason" optional field to ramoops DT node
WeiXiong Liao (10):
pstore/zone: Introduce common layer to manage storage zones
pstore/blk: Introduce backend for block devices
pstore/zone,blk: Add support for pmsg frontend
pstore/zone,blk: Add console frontend support
pstore/zone,blk: Add ftrace frontend support
Documentation: Add details for pstore/blk
pstore/zone: Provide way to skip "broken" zone for MTD devices
pstore/blk: Provide way to query pstore configuration
pstore/blk: Support non-block storage devices
mtd: Support kmsg dumper based on pstore/blk
Documentation/admin-guide/pstore-blk.rst | 243 ++++
Documentation/admin-guide/ramoops.rst | 14 +-
.../bindings/reserved-memory/ramoops.txt | 13 +-
MAINTAINERS | 1 +
arch/powerpc/kernel/nvram_64.c | 4 +-
drivers/mtd/Kconfig | 10 +
drivers/mtd/Makefile | 1 +
drivers/mtd/mtdpstore.c | 578 ++++++++
drivers/platform/chrome/chromeos_pstore.c | 2 +-
fs/pstore/Kconfig | 109 ++
fs/pstore/Makefile | 6 +
fs/pstore/blk.c | 517 +++++++
fs/pstore/ftrace.c | 54 +
fs/pstore/inode.c | 129 +-
fs/pstore/internal.h | 11 +-
fs/pstore/platform.c | 117 +-
fs/pstore/ram.c | 155 +--
fs/pstore/zone.c | 1465 ++++++++++++++++++++
include/linux/kmsg_dump.h | 12 +-
include/linux/pstore.h | 9 +-
include/linux/pstore_blk.h | 118 ++
include/linux/pstore_ram.h | 2 +-
include/linux/pstore_zone.h | 60 +
kernel/printk/printk.c | 32 +-
kernel/reboot.c | 6 +-
tools/testing/selftests/pstore/pstore_tests | 2 +-
26 files changed, 3464 insertions(+), 206 deletions(-)
create mode 100644 Documentation/admin-guide/pstore-blk.rst
create mode 100644 drivers/mtd/mtdpstore.c
create mode 100644 fs/pstore/blk.c
create mode 100644 fs/pstore/zone.c
create mode 100644 include/linux/pstore_blk.h
create mode 100644 include/linux/pstore_zone.h
--
Kees Cook
^ permalink raw reply [relevance 71%]
* [GIT PULL] overflow helper addition for v5.8-rc2
@ 2020-06-19 2:42 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2020-06-19 2:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Gustavo A. R. Silva
Hi Linus,
Please pull this tiny overflow helper addition for v5.8-rc2. During the
treewide clean-ups of zero-length "flexible arrays", the struct_size()
helper was heavily used, but it was noticed that many times it would
have been nice to have an additional helper to get the size of just the
flexible array itself. This need appears to be even more common when
cleaning up the 1-byte array "flexible arrays", so Gustavo implemented
it. I'd love to get this landed before -rc2 so it can be used during
the v5.9 dev cycle to ease the 1-byte array cleanups.
Thanks!
-Kees
The following changes since commit b3a9e3b9622ae10064826dccb4f7a52bd88c7407:
Linux 5.8-rc1 (2020-06-14 12:45:04 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/overflow-v5.8-rc2
for you to fetch changes up to b19d57d0f3cc6f1022edf94daf1d70506a09e3c2:
overflow.h: Add flex_array_size() helper (2020-06-16 20:45:08 -0700)
----------------------------------------------------------------
Add flex-array size helper
----------------------------------------------------------------
Gustavo A. R. Silva (1):
overflow.h: Add flex_array_size() helper
include/linux/overflow.h | 25 +++++++++++++++++++++----
1 file changed, 21 insertions(+), 4 deletions(-)
--
Kees Cook
^ permalink raw reply [relevance 92%]
* Re: [GIT PULL][PATCH v6 0/8] Add support for ZSTD-compressed kernel and initramfs
@ 2020-07-07 21:32 91% ` Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2020-07-07 21:32 UTC (permalink / raw)
To: Borislav Petkov, Thomas Gleixner, x86
Cc: Nick Terrell, linux-kernel, Chris Mason, linux-kbuild, gregkh,
Petr Malat, Kernel Team, Adam Borowski, Patrick Williams, rmikey,
mingo, Patrick Williams, Sedat Dilek, Norbert Lange,
Andrew Morton, Nick Terrell
On Mon, Jul 06, 2020 at 08:45:56PM -0700, Nick Terrell wrote:
> From: Nick Terrell <terrelln@fb.com>
>
> Please pull from
>
> git@github.com:terrelln/linux.git tags/v6-zstd
>
> to get these changes. Alternatively the patchset is included.
>
> Hi all,
>
> This patch set adds support for a ZSTD-compressed kernel, ramdisk, and
> initramfs in the kernel boot process. ZSTD-compressed ramdisk and initramfs
> are supported on all architectures. The ZSTD-compressed kernel is only
> hooked up to x86 in this patch set.
Hello x86 maintainers!
I think this series is ready to go. Notes below...
> [...]
> x86: bump ZO_z_extra_bytes margin for zstd
The above patch is really the only thing that has any external visibility
to kernels that have ZSTD disabled. Given the ratios of memory sizes
involved (an extra 64K when we're dealing with 2MB windows) seems
reasonable to me. If that isn't acceptable, it should be trivial to make
it CONFIG-selectable (like we already do with BOOT_HEAP_SIZE).
What do you think? If the non-x86 parts should land first in -mm, I
guess that would be okay, but I think it makes sense for all of this to
go via -tip.
-Kees
--
Kees Cook
^ permalink raw reply [relevance 91%]
* [GIT PULL] kallsyms_show_value() refactoring for v5.8-rc5
@ 2020-07-08 23:16 86% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2020-07-08 23:16 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Alexei Starovoitov, bpf, Daniel Borkmann,
Dominik Czarnota, Greg Kroah-Hartman, Jessica Yu,
Luis Chamberlain, Masami Hiramatsu
Hi Linus,
Please pull this kallsyms_show_value() refactoring for v5.8-rc5. I'm not
delighted by the timing of getting these changes to you, but it does fix
a handful of kernel address exposures, and no one has screamed yet at the
patches nor their existence in -next for a few days. Folks have reviewed
(and even tested!) the series. :)
(I'm leaving the more experimental current_cred() WARN() stuff for
later, obviously.)
Thanks!
-Kees
The following changes since commit 48778464bb7d346b47157d21ffde2af6b2d39110:
Linux 5.8-rc2 (2020-06-21 15:45:29 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/kallsyms_show_value-v5.8-rc5
for you to fetch changes up to 2c79583927bb8154ecaa45a67dde97661d895ecd:
selftests: kmod: Add module address visibility test (2020-07-08 16:01:36 -0700)
----------------------------------------------------------------
Refactor kallsyms_show_value() users for correct cred
Several users of kallsyms_show_value() were performing checks not
during "open". Refactor everything needed to gain proper checks against
file->f_cred for modules, kprobes, and bpf.
----------------------------------------------------------------
Kees Cook (6):
kallsyms: Refactor kallsyms_show_value() to take cred
module: Refactor section attr into bin attribute
module: Do not expose section addresses to non-CAP_SYSLOG
kprobes: Do not expose probe addresses to non-CAP_SYSLOG
bpf: Check correct cred for CAP_SYSLOG in bpf_dump_raw_ok()
selftests: kmod: Add module address visibility test
include/linux/filter.h | 4 +--
include/linux/kallsyms.h | 5 ++--
kernel/bpf/syscall.c | 37 +++++++++++++++-----------
kernel/kallsyms.c | 17 +++++++-----
kernel/kprobes.c | 4 +--
kernel/module.c | 51 +++++++++++++++++++-----------------
net/core/sysctl_net_core.c | 2 +-
tools/testing/selftests/kmod/kmod.sh | 36 +++++++++++++++++++++++++
8 files changed, 103 insertions(+), 53 deletions(-)
--
Kees Cook
^ permalink raw reply [relevance 86%]
* [GIT PULL] pstore update for v5.9-rc1
@ 2020-08-03 18:46 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2020-08-03 18:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Kees Cook, Matteo Croce
Hi Linus,
Please pull this tiny pstore update for v5.9-rc1, which fixes a very
corner-case build failure.
Thanks!
-Kees
The following changes since commit 48778464bb7d346b47157d21ffde2af6b2d39110:
Linux 5.8-rc2 (2020-06-21 15:45:29 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/pstore-v5.9-rc1
for you to fetch changes up to fd49e03280e596e54edb93a91bc96170f8e97e4a:
pstore: Fix linking when crypto API disabled (2020-07-06 19:42:31 -0700)
----------------------------------------------------------------
pstore update
- Fix linking when crypto API disabled (Matteo Croce)
----------------------------------------------------------------
Matteo Croce (1):
pstore: Fix linking when crypto API disabled
fs/pstore/platform.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--
Kees Cook
^ permalink raw reply [relevance 92%]
* [GIT PULL] gcc-plugins updates for v5.9-rc1
@ 2020-08-03 18:51 90% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2020-08-03 18:51 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Alexander A. Klimov, Alexander Popov, Kees Cook,
Miguel Ojeda
Hi Linus,
Please pull these gcc-plugins updates for v5.9-rc1. It is primarily
improvements to STACKLEAK from Alexander Popov, along with some additional
cleanups.
Thanks!
-Kees
The following changes since commit 48778464bb7d346b47157d21ffde2af6b2d39110:
Linux 5.8-rc2 (2020-06-21 15:45:29 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/gcc-plugins-v5.9-rc1
for you to fetch changes up to 496b24ec6d47f2d304a0c5836ba4b1bb5d30bab8:
gcc-plugins: Replace HTTP links with HTTPS ones (2020-07-13 09:29:09 -0700)
----------------------------------------------------------------
GCC plugins updates for v5.9-rc1
- Update URLs for HTTPS scheme where available (Alexander A. Klimov)
- Improve STACKLEAK code generation on x86 (Alexander Popov)
----------------------------------------------------------------
Alexander A. Klimov (1):
gcc-plugins: Replace HTTP links with HTTPS ones
Alexander Popov (4):
gcc-plugins/stackleak: Don't instrument itself
ARM: vdso: Don't use gcc plugins for building vgettimeofday.c
gcc-plugins/stackleak: Use asm instrumentation to avoid useless register saving
gcc-plugins/stackleak: Add 'verbose' plugin parameter
arch/arm/vdso/Makefile | 2 +-
include/linux/compiler_attributes.h | 13 ++
kernel/Makefile | 1 +
kernel/stackleak.c | 16 +-
scripts/Makefile.gcc-plugins | 2 +
scripts/gcc-plugins/cyc_complexity_plugin.c | 2 +-
scripts/gcc-plugins/sancov_plugin.c | 2 +-
scripts/gcc-plugins/stackleak_plugin.c | 248 ++++++++++++++++++++++++----
scripts/gcc-plugins/structleak_plugin.c | 2 +-
9 files changed, 241 insertions(+), 47 deletions(-)
--
Kees Cook
^ permalink raw reply [relevance 90%]
* [GIT PULL] var-init update for v5.9-rc1
@ 2020-08-03 18:57 92% Kees Cook
0 siblings, 0 replies; 200+ results
From: Kees Cook @ 2020-08-03 18:57 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Alexander Potapenko, Greg Kroah-Hartman, Kees Cook,
Maciej Żenczykowski, Nick Desaulniers
Hi Linus,
Please pull this var-init update for v5.9-rc1. (This is the tree formerly
known as "mem-init", which you correctly pointed out was not a good
name.) This adds the "zero" init option from Clang, which is being used
widely in production builds of Android and Chrome OS (though it keeps the
"pattern" init, which is better for debug builds).
Thanks!
-Kees
The following changes since commit b3a9e3b9622ae10064826dccb4f7a52bd88c7407:
Linux 5.8-rc1 (2020-06-14 12:45:04 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/var-init-v5.9-rc1
for you to fetch changes up to f0fe00d4972a8cd4b98cc2c29758615e4d51cdfe:
security: allow using Clang's zero initialization for stack variables (2020-06-16 02:06:23 -0700)
----------------------------------------------------------------
Automatic variable initialization updates for v5.9-rc1
- Introduce CONFIG_INIT_STACK_ALL_ZERO (Alexander Potapenko)
----------------------------------------------------------------
glider@google.com (1):
security: allow using Clang's zero initialization for stack variables
Makefile | 13 +++++++++++--
init/main.c | 12 +++++++-----
security/Kconfig.hardening | 29 +++++++++++++++++++++++++----
3 files changed, 43 insertions(+), 11 deletions(-)
--
Kees Cook
^ permalink raw reply [relevance 92%]
Results 1-200 of ~400 next (newer) | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2012-12-14 0:23 59% [GIT PULL] CONFIG_EXPERIMENTAL removal for for 3.8 Kees Cook
2012-12-19 18:42 67% [RESEND][GIT PULL] CONFIG_EXPERIMENTAL removal " Kees Cook
2013-07-13 11:21 [GIT pull] x86 updates for 3.11 Thomas Gleixner
2013-07-13 22:40 ` Linus Torvalds
2013-07-14 1:06 ` H. Peter Anvin
2013-07-15 20:45 ` Thomas Gleixner
2013-07-15 21:10 92% ` Kees Cook
2014-01-20 16:47 [GIT PULL] x86/kaslr for v3.14 H. Peter Anvin
2014-01-20 22:54 ` Linus Torvalds
2014-01-20 23:12 ` Linus Torvalds
2014-01-20 23:13 ` H. Peter Anvin
2014-01-21 9:00 ` Peter Zijlstra
2014-01-21 14:20 ` H. Peter Anvin
2014-01-21 18:37 92% ` Kees Cook
2014-01-21 5:18 92% ` Kees Cook
2014-01-26 10:16 ` Richard Weinberger
2014-01-27 5:33 ` H. Peter Anvin
2014-01-27 6:49 ` Richard Weinberger
2014-01-27 6:51 ` H. Peter Anvin
2014-01-30 22:07 ` Vivek Goyal
2014-01-31 16:57 92% ` Kees Cook
2014-02-07 14:49 ` Vivek Goyal
2014-02-07 19:07 ` H. Peter Anvin
2014-02-07 19:44 92% ` Kees Cook
2014-01-27 17:05 87% ` Kees Cook
2014-01-27 17:20 ` Richard Weinberger
2014-01-27 17:24 92% ` Kees Cook
2014-11-16 9:07 [GIT PULL] x86 fixes Ingo Molnar
2014-11-17 7:42 ` Markus Trippelsdorf
2014-11-17 8:27 ` Markus Trippelsdorf
2014-11-17 13:58 ` Ingo Molnar
2014-11-17 21:02 92% ` Kees Cook
2014-11-17 21:21 ` Markus Trippelsdorf
2014-11-17 23:09 92% ` Kees Cook
2015-11-03 11:16 [GIT PULL] x86/mm changes for v4.4 Ingo Molnar
2015-11-04 19:26 ` Linus Torvalds
2015-11-04 23:39 ` Dave Jones
2015-11-05 1:31 ` Linus Torvalds
2015-11-05 2:17 ` Dave Jones
2015-11-05 21:27 ` Linus Torvalds
2015-11-06 6:55 ` Ingo Molnar
2015-11-06 12:39 ` Matt Fleming
2015-11-07 7:09 ` Ingo Molnar
2015-11-07 7:39 ` Ard Biesheuvel
2015-11-08 6:58 91% ` Kees Cook
2015-11-08 7:55 ` Ard Biesheuvel
2015-11-09 21:08 92% ` Kees Cook
2015-11-10 7:08 ` Ard Biesheuvel
2015-11-10 20:11 92% ` Kees Cook
2016-07-25 21:31 88% [GIT PULL] pstore updates for v4.8 Kees Cook
2016-07-26 21:55 81% [GIT PULL] usercopy protection " Kees Cook
2016-07-27 3:53 92% ` Kees Cook
2016-07-30 4:36 92% ` Kees Cook
2016-08-01 21:29 92% [GIT PULL] lkdtm update for v4.8-rc1 Kees Cook
2016-08-02 19:00 [GIT PULL] kbuild changes " Michal Marek
2016-08-02 20:41 ` Linus Torvalds
2016-08-02 20:55 92% ` Kees Cook
2016-08-02 21:00 ` Linus Torvalds
2016-08-02 22:11 92% ` Kees Cook
2016-08-02 22:20 83% [GIT PULL] gcc-plugins update " Kees Cook
2016-08-08 22:38 ` Linus Torvalds
2016-08-08 23:18 69% ` Kees Cook
2016-08-05 18:28 91% [GIT PULL] pstore fixes " Kees Cook
2016-08-09 1:04 91% [GIT PULL] gcc-plugin-infrastructure updates for v4.8-rc2 Kees Cook
2016-08-23 2:22 92% [GIT PULL] hardened usercopy fixes for v4.8-rc4 Kees Cook
2016-08-23 19:34 92% [GIT PULL] seccomp fix " Kees Cook
2016-08-30 22:28 92% ` Kees Cook
2016-08-30 23:15 92% [GIT PULL] seccomp fix for v4.8-rc5 Kees Cook
2016-09-06 19:37 91% [GIT PULL] usercopy fixes for v4.8-rc6 Kees Cook
2016-09-07 16:33 ` Linus Torvalds
2016-09-07 16:38 92% ` Kees Cook
2016-09-07 16:29 92% [GIT PULL] seccomp " Kees Cook
2016-09-08 4:31 ` James Morris
2016-09-08 15:53 92% ` Kees Cook
2016-09-07 18:36 92% [GIT PULL] usercopy fixes for v4.8-rc6-part2 Kees Cook
2016-09-07 19:15 ` Linus Torvalds
2016-09-07 21:32 92% ` Kees Cook
2016-09-07 21:48 92% ` Kees Cook
2016-09-20 23:15 92% [GIT PULL] usercopy fix for v4.8-rc8 Kees Cook
2016-10-05 21:43 86% [GIT PULL] pstore updates for v4.9-rc1 Kees Cook
2016-10-10 22:04 87% [GIT PULL] gcc-plugins " Kees Cook
2016-11-01 17:32 92% [GIT PULL] lkdtm fixes for v4.9-rc4 Kees Cook
2016-11-01 20:19 ` Greg KH
2016-11-01 21:22 92% ` Kees Cook
2016-11-01 17:39 92% [GIT PULL] gcc-plugin " Kees Cook
2016-11-01 17:46 92% [GIT PULL] seccomp " Kees Cook
2016-11-01 22:43 ` James Morris
2016-11-02 2:07 92% ` Kees Cook
2016-12-07 23:35 84% [GIT PULL] pstore updates for v4.10-rc1 Kees Cook
2016-12-07 23:59 92% [GIT PULL] gcc-plugins " Kees Cook
2017-01-03 20:14 92% [GIT PULL] gcc-plugins updates for v4.10-rc3 Kees Cook
2017-02-09 19:56 92% [GIT PULL] pstore fix for v4.10-rc8 Kees Cook
2017-02-21 19:52 92% [GIT PULL] pstore updates for v4.11-rc1 Kees Cook
2017-02-21 20:03 92% [GIT PULL] usercopy " Kees Cook
2017-02-21 20:08 83% [GIT PULL] rodata " Kees Cook
2017-02-21 20:16 79% [GIT PULL] gcc-plugins " Kees Cook
2017-02-22 2:34 ` Linus Torvalds
2017-02-22 5:07 92% ` Kees Cook
2017-02-22 5:16 89% [GIT PULL] gcc-plugins updates for v4.11-rc1 (take 2) Kees Cook
2017-02-23 23:47 92% [GIT PULL] usercopy fix for v4.11-rc1 Kees Cook
2017-03-09 21:39 92% [GIT PULL] gcc-plugins updates for v4.11-rc2 Kees Cook
2017-04-12 18:54 92% [GIT PULL] devmem fix for v4.11-rc7 Kees Cook
2017-05-01 18:23 81% [GIT PULL] pstore updates for v4.12-rc1 Kees Cook
2017-05-01 18:34 92% [GIT PULL] usercopy " Kees Cook
2017-05-16 18:54 92% [GIT PULL] pstore update for v4.12-rc2 Kees Cook
2017-05-23 0:01 92% [GIT PULL] pstore fix for v4.12-rc3 Kees Cook
2017-06-01 20:25 88% [GIT PULL] gcc-plugin updates for v4.12-rc4 Kees Cook
2017-06-26 17:02 92% [GIT PULL] seccomp updates for next Kees Cook
2017-07-05 4:29 88% [GIT PULL] pstore updates for v4.13-rc1 Kees Cook
2017-07-05 5:05 81% [GIT PULL] gcc-plugins " Kees Cook
2017-07-05 19:07 ` Linus Torvalds
2017-07-05 20:40 ` Ard Biesheuvel
2017-07-05 21:35 ` Linus Torvalds
2017-07-05 21:48 ` Arnd Bergmann
2017-07-05 21:52 92% ` Kees Cook
2017-07-05 21:49 89% ` Kees Cook
2017-07-06 9:12 [git pull] vfs.git pile 11 Al Viro
2017-07-06 19:45 96% ` Kees Cook
2017-07-17 20:24 69% [GIT PULL] gcc-plugins updates for v4.13-rc2 Kees Cook
2017-08-02 18:58 92% [GIT PULL] lkdtm updates for next Kees Cook
2017-08-15 19:43 92% [GIT PULL] lkdtm updates for next, part 2 Kees Cook
2017-08-15 22:03 86% [GIT PULL] seccomp updates for next Kees Cook
2017-09-04 10:29 [GIT PULL] Security subsystem updates for 4.14 James Morris
2017-09-07 18:19 ` Linus Torvalds
2017-09-08 4:48 ` James Morris
2017-09-08 7:09 ` Christoph Hellwig
2017-09-08 17:25 ` Linus Torvalds
2017-09-08 17:36 ` Paul Moore
2017-09-10 4:32 ` James Morris
2017-09-14 21:09 92% ` Kees Cook
2017-09-14 21:13 ` James Morris
2017-09-14 21:25 92% ` Kees Cook
2017-09-05 19:51 92% [GIT PULL] pstore updates for v4.14-rc1 Kees Cook
2017-09-05 20:02 88% [GIT PULL] gcc-plugins " Kees Cook
2017-09-05 20:11 83% [GIT PULL] secureexec update " Kees Cook
2017-09-22 18:34 85% [GIT PULL] seccomp updates for v4.14-rc2 Kees Cook
2017-09-27 10:29 92% [GIT PULL] x86-refcount fix for v4.14-rc3 Kees Cook
2017-09-27 10:57 ` Ingo Molnar
2017-09-27 11:47 92% ` Kees Cook
2017-09-28 5:57 92% [GIT PULL] seccomp " Kees Cook
2017-10-06 15:31 92% [GIT PULL] lkdtm updates for -next Kees Cook
2017-10-06 20:20 92% [GIT PULL] lkdtm updates for -next (take 2) Kees Cook
2017-10-10 18:50 92% [GIT PULL] seccomp fix for v4.14-rc5 Kees Cook
2017-10-27 9:36 85% [GIT PULL] timers-conversion updates for next Kees Cook
2017-11-01 19:05 71% [GIT PULL] timers-conversion updates for next (part2) Kees Cook
2017-11-02 23:05 72% [GIT PULL] timers-conversion updates for next (part 3) Kees Cook
2017-11-06 22:01 84% [GIT PULL] timers-conversion updates for next (part 4) Kees Cook
2017-11-08 23:59 89% [GIT PULL] timers-conversion updates for next (part 5) Kees Cook
2017-11-13 7:29 70% [GIT PULL] usercopy whitelisting for v4.15-rc1 Kees Cook
2017-11-16 7:45 92% ` Kees Cook
2017-11-16 19:32 82% [GIT PULL] tree-dependent timer conversions " Kees Cook
2017-11-17 16:54 67% [GIT PULL] usercopy whitelisting " Kees Cook
2017-11-17 17:35 ` Linus Torvalds
2017-11-17 17:45 ` Paolo Bonzini
2017-11-17 20:35 91% ` Kees Cook
2017-11-17 21:13 ` Linus Torvalds
2017-11-17 22:19 92% ` Kees Cook
2017-11-20 19:50 ` Matthew Garrett
[not found] ` <CA+55aFyMtpYASreqGuRmJoB8isJnhOxsWMa4uoQu6WtBJDHU6A@mail.gmail.com>
2017-11-20 23:29 ` Matthew Garrett
2017-11-21 0:42 73% ` Kees Cook
2017-11-22 0:19 39% [GIT PULL] final timer conversion update " Kees Cook
2017-11-22 0:41 92% ` Kees Cook
2017-11-29 0:38 92% [GIT PULL] seccomp updates for next Kees Cook
2017-11-29 4:59 [GIT PULL] hash addresses printed with %p Tobin C. Harding
2017-11-29 19:22 ` Linus Torvalds
2017-11-29 19:39 ` Linus Torvalds
2017-11-29 21:31 92% ` Kees Cook
2017-11-29 21:08 ` Tobin C. Harding
2017-11-29 21:14 ` Linus Torvalds
2017-11-29 21:36 ` Linus Torvalds
2017-11-30 16:32 ` Greg Kroah-Hartman
2017-11-30 17:10 ` Greg Kroah-Hartman
2017-11-30 17:18 ` Ard Biesheuvel
2017-12-01 9:48 ` Greg Kroah-Hartman
2017-12-01 9:54 ` Ard Biesheuvel
2017-12-01 15:34 ` Greg Kroah-Hartman
2017-12-01 16:33 92% ` Kees Cook
2018-01-07 16:21 [GIT PULL] parisc architecture fixes for 4.15-rc7 Helge Deller
2018-01-09 23:03 92% ` Kees Cook
2018-01-29 10:54 61% [GIT PULL] hardened usercopy whitelisting for v4.16-rc1 Kees Cook
2018-01-29 10:59 92% [GIT PULL] pstore update " Kees Cook
2018-02-07 3:00 92% [GIT PULL] gcc-plugins updates " Kees Cook
2018-02-22 1:04 92% [GIT PULL] seccomp updates for v4.16-rc3 Kees Cook
2018-02-22 1:11 92% Kees Cook
2018-02-27 1:13 92% [GIT PULL] seccomp update for v4.16-rc4 Kees Cook
2018-03-30 23:29 [GIT PULL] Kernel lockdown for secure boot David Howells
2018-03-31 0:46 ` James Morris
2018-04-03 0:37 ` Andy Lutomirski
2018-04-03 0:59 86% ` Kees Cook
2018-04-03 7:06 ` David Howells
2018-04-03 15:11 ` Andy Lutomirski
2018-04-03 16:29 ` Matthew Garrett
2018-04-03 16:45 ` Andy Lutomirski
2018-04-03 18:45 84% ` Kees Cook
2018-04-03 19:01 ` Andy Lutomirski
2018-04-03 19:07 92% ` Kees Cook
2018-04-02 16:26 90% [GIT PULL] pstore updates for v4.17-rc1 Kees Cook
2018-04-03 18:06 [GIT PULL] x86/build changes for v4.17 Matthias Kaehlcke
2018-04-04 9:30 ` Peter Zijlstra
2018-04-04 19:17 ` Matthias Kaehlcke
2018-04-04 20:33 ` Arnd Bergmann
2018-04-04 20:58 ` Matthias Kaehlcke
2018-04-04 21:11 ` Arnd Bergmann
2018-04-04 21:46 ` Matthias Kaehlcke
2018-04-04 21:59 ` Linus Torvalds
2018-04-04 22:17 ` Matthias Kaehlcke
2018-04-04 22:39 ` Linus Torvalds
2018-04-04 23:31 ` Matthias Kaehlcke
2018-04-05 0:05 ` Linus Torvalds
2018-04-05 0:20 92% ` Kees Cook
2018-04-04 10:31 [GIT PULL] USB/PHY driver patches for 4.17-rc1 Greg KH
2018-04-05 6:31 92% ` Kees Cook
2018-04-08 17:20 92% [GIT PULL] pstore updates for v4.17-rc1 (part 2) Kees Cook
2018-06-04 4:49 87% [GIT PULL] rslib updates for v4.18-rc1 Kees Cook
2018-06-06 18:40 63% [GIT PULL] overflow changes " Kees Cook
2018-06-12 23:35 16% [GIT PULL] overflow updates (part 2) " Kees Cook
2018-06-13 1:44 ` Linus Torvalds
2018-06-13 19:07 72% ` Kees Cook
2018-08-04 15:04 92% [GIT PULL] usercopy fix for v4.18-rc8 Kees Cook
2018-08-13 20:33 92% [GIT PULL] hardened-usercopy updates for v4.19-rc1 Kees Cook
2018-08-13 20:37 92% [GIT PULL] pstore update " Kees Cook
2018-08-13 21:43 71% [GIT PULL] gcc-plugin updates " Kees Cook
2018-08-15 16:41 ` Linus Torvalds
2018-08-15 18:35 85% ` Kees Cook
2018-08-15 19:04 ` Linus Torvalds
2018-08-15 19:45 86% ` Kees Cook
2018-08-15 20:18 ` Linus Torvalds
2018-08-15 20:56 87% ` Kees Cook
2018-08-15 18:40 92% [GIT PULL] gcc-plugin cleanups " Kees Cook
2018-08-16 23:54 91% [GIT PULL] VLA removal leftovers " Kees Cook
2018-08-21 18:06 72% [GIT PULL] stackleak plugin for v4.19-rc1 (take 2) Kees Cook
2018-08-23 17:28 92% [GIT PULL] gcc-plugins update for v4.19-rc1 (fix) Kees Cook
2018-08-24 7:42 [GIT PULL] s390 patches for the 4.19 merge window #2 Martin Schwidefsky
2018-09-05 0:16 92% ` Kees Cook
2018-09-13 16:32 92% [GIT PULL] pstore fixes for v4.19-rc4 Kees Cook
2018-09-30 17:29 92% [GIT PULL] pstore fix for v4.19-rc7 Kees Cook
2018-10-11 16:52 90% [GIT PULL] allocator argument fixes for v4.19-rc8 Kees Cook
2018-10-18 23:05 92% [GIT PULL] loadpin updates for security-next Kees Cook
2018-10-22 14:24 92% [GIT PULL] pstore updates for v4.20-rc1 Kees Cook
2018-10-23 8:41 Git pull ack emails Linus Torvalds
2018-10-24 22:21 84% ` Kees Cook
2018-10-24 19:14 73% [GIT PULL] gcc-plugin stackleak for v4.20-rc1 Kees Cook
2018-10-28 17:24 89% [GIT PULL] VLA removal " Kees Cook
2018-11-29 23:15 92% [GIT PULL] pstore fix for v4.20-rc5 Kees Cook
2018-11-30 17:18 92% [GIT PULL] gcc-plugins " Kees Cook
2018-12-07 17:08 92% [GIT PULL] gcc-plugin updates for v4.20-rc6 Kees Cook
2018-12-12 23:16 92% [GIT PULL] seccomp updates for next Kees Cook
2018-12-14 16:25 92% [GIT PULL] seccomp updates for next (part2) Kees Cook
2018-12-17 18:00 92% ` Kees Cook
2018-12-17 23:50 85% [GIT PULL] pstore updates for v4.21-rc1 Kees Cook
2018-12-18 0:01 90% [GIT PULL] gcc-plugins update " Kees Cook
2018-12-31 4:15 [GIT PULL] security: seccomp changes for v4.21 James Morris
2019-01-07 10:15 ` Ingo Molnar
2019-01-07 21:09 92% ` Kees Cook
2019-01-07 21:53 ` Tycho Andersen
2019-01-07 22:04 92% ` Kees Cook
2019-01-08 21:04 [GIT PULL] seccomp: build fix for v5.0-rc2 James Morris
2019-01-08 21:11 92% ` Kees Cook
2019-01-08 21:35 73% [GIT PULL] blob-stacking updates for security-next Kees Cook
2019-01-11 10:38 ` Tetsuo Handa
2019-01-11 17:44 92% ` Kees Cook
2019-01-09 20:12 92% [GIT PULL] lkdtm updates for -next Kees Cook
2019-01-20 22:20 92% [GIT PULL] gcc-plugin fixes for v5.0-rc4 Kees Cook
2019-01-20 23:06 92% [GIT PULL] pstore " Kees Cook
2019-03-04 17:27 92% [GIT PULL] pstore updates for v5.1-rc1 Kees Cook
2019-03-04 17:48 89% [GIT PULL] gcc-plugin " Kees Cook
2019-03-10 11:33 [GIT pull] core udpate for 5.1 Thomas Gleixner
2019-03-10 11:33 ` [GIT pull] x86/asm " Thomas Gleixner
2019-03-10 21:43 ` Linus Torvalds
2019-03-11 14:22 ` Thomas Gleixner
2019-03-11 15:39 ` Linus Torvalds
2019-03-11 16:55 91% ` Kees Cook
2019-03-11 17:41 ` Linus Torvalds
2019-03-11 19:14 92% ` Kees Cook
[not found] ` <CAHk-=whQYG7iHO8Gv2Ka2_2tXNJkX1LdsyqKUZ=EO0aP6uS+2g@mail.gmail.com>
2019-03-11 20:36 92% ` Kees Cook
2019-04-29 19:58 91% [GIT PULL] seccomp fixes for v5.1-rc8 Kees Cook
2019-05-06 17:21 91% [GIT PULL] compiler-based variable-init updates for v5.2-rc1 Kees Cook
2019-05-09 17:19 92% [GIT PULL] lkdtm fixes for next Kees Cook
2019-05-13 21:05 92% [GIT PULL] gcc-plugins fixes for v5.2-rc1 Kees Cook
2019-05-31 2:18 92% [GIT PULL] gcc-plugins update for v5.2-rc3 Kees Cook
2019-06-05 3:20 92% [GIT PULL] pstore fixes for v5.2-rc4 Kees Cook
2019-06-18 4:00 92% [GIT PULL] meminit fix for v5.2-rc6 Kees Cook
2019-07-08 16:27 [GIT PULL] x86/topology changes for v5.3 Ingo Molnar
2019-07-09 21:20 ` Linus Torvalds
2019-07-09 21:26 ` Linus Torvalds
2019-07-09 21:45 ` Linus Torvalds
2019-07-09 22:00 ` Linus Torvalds
2019-07-09 22:27 ` Thomas Gleixner
2019-07-09 23:00 ` Thomas Gleixner
2019-07-09 23:17 ` Thomas Gleixner
2019-07-10 0:31 92% ` Kees Cook
2019-07-10 11:27 ` Xi Ruoyao
2019-07-10 12:01 ` Xi Ruoyao
2019-07-10 12:19 ` Thomas Gleixner
2019-07-10 12:31 ` Jiri Kosina
2019-07-10 13:25 ` Xi Ruoyao
2019-07-10 13:44 ` Peter Zijlstra
2019-07-10 14:22 ` Jiri Kosina
2019-07-11 7:11 ` Nadav Amit
2019-07-11 8:01 ` Peter Zijlstra
2019-07-11 15:08 92% ` Kees Cook
2019-07-10 0:59 ` Linus Torvalds
2019-07-10 1:08 ` Linus Torvalds
2019-07-10 3:21 ` Linus Torvalds
2019-07-10 5:15 ` Linus Torvalds
2019-07-10 5:33 92% ` Kees Cook
2019-07-09 4:11 92% [GIT PULL] pstore updates for v5.3-rc1 Kees Cook
2019-07-09 4:18 92% [GIT PULL] loadpin update " Kees Cook
2019-07-28 19:21 92% [GIT PULL] meminit fix for v5.3-rc2 Kees Cook
2019-07-28 19:43 ` Linus Torvalds
2019-07-28 22:16 92% ` Kees Cook
2019-08-25 22:23 92% [GIT PULL drivers/misc] lkdtm updates for next Kees Cook
2019-09-16 21:44 92% [GIT PULL] gcc-plugins update for v5.4-rc1 Kees Cook
2019-09-26 17:33 61% [GIT PULL] treewide conversion to sizeof_member() " Kees Cook
2019-09-26 20:06 ` Linus Torvalds
2019-09-26 20:56 92% ` Kees Cook
2019-10-02 18:19 92% ` renaming FIELD_SIZEOF to sizeof_member (was Re: [GIT PULL] treewide conversion to sizeof_member() for v5.4-rc1) Kees Cook
2019-09-26 18:35 92% [GIT PULL] usercopy fix for v5.4-rc1 Kees Cook
2019-11-26 16:25 79% [GIT PULL] seccomp updates for v5.5-rc1 Kees Cook
2019-11-26 16:29 92% [GIT PULL] pstore update " Kees Cook
2019-12-07 19:48 58% [GIT PULL] treewide conversion to sizeof_member() " Kees Cook
2019-12-09 19:05 63% [GIT PULL] treewide conversion to sizeof_field() for v5.5-rc2 Kees Cook
2020-01-02 20:55 92% [GIT PULL] pstore fixes for v5.5-rc5 Kees Cook
2020-01-02 21:28 91% [GIT PULL] seccomp " Kees Cook
2020-01-02 21:38 92% [GIT PULL] gcc-plugins fix " Kees Cook
2020-01-02 21:48 92% [GIT PULL] FIELD_SIZEOF() removal " Kees Cook
2020-01-10 4:46 92% [GIT PULL] pstore fix for v5.5-rc6 Kees Cook
2020-03-03 4:25 89% [GIT PULL] READ_IMPLIES_EXEC cleanup for -tip next Kees Cook
2020-03-30 4:16 92% [GIT PULL] seccomp updates for v5.7-rc1 Kees Cook
2020-03-30 4:21 92% [GIT PULL] pstore " Kees Cook
2020-05-04 17:46 92% [GIT PULL] gcc-plugins fixes for v5.7-rc5 Kees Cook
2020-06-01 2:57 71% [GIT PULL] pstore updates for v5.8-rc1 Kees Cook
2020-06-19 2:42 92% [GIT PULL] overflow helper addition for v5.8-rc2 Kees Cook
2020-07-07 3:45 [GIT PULL][PATCH v6 0/8] Add support for ZSTD-compressed kernel and initramfs Nick Terrell
2020-07-07 21:32 91% ` Kees Cook
2020-07-08 23:16 86% [GIT PULL] kallsyms_show_value() refactoring for v5.8-rc5 Kees Cook
2020-08-03 18:46 92% [GIT PULL] pstore update for v5.9-rc1 Kees Cook
2020-08-03 18:51 90% [GIT PULL] gcc-plugins updates " Kees Cook
2020-08-03 18:57 92% [GIT PULL] var-init update " Kees Cook
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).