kernel-hardening mailing list - 2018/08

Follow @Openwall on Twitter for new release announcements and other news

[<prev month] [next month>] [year] [list]

kernel-hardening mailing list - 2018/08

Mon	Tue	Wed	Thu	Fri	Sat	Sun
		¹	² 4	³	⁴	⁵
⁶ 14	⁷ 13	⁸ 2	⁹	¹⁰	¹¹	¹²
¹³ 1	¹⁴	¹⁵ 4	¹⁶ 19	¹⁷ 9	¹⁸ 1	¹⁹
²⁰ 13	²¹ 17	²² 5	²³ 3	²⁴ 7	²⁵	²⁶
²⁷ 14	²⁸ 13	²⁹ 5	³⁰ 2	³¹ 4

Messages by day:

August 2 (4 messages)

[RFC/PoC PATCH 0/3] arm64: basic ROP mitigation (Ard Biesheuvel <ard.biesheuvel@...aro.org>)
[RFC/PoC PATCH 1/3] arm64: use wrapper macro for bl/blx instructions from asm code (Ard Biesheuvel <ard.biesheuvel@...aro.org>)
[RFC/PoC PATCH 2/3] gcc: plugins: add ROP shield plugin for arm64 (Ard Biesheuvel <ard.biesheuvel@...aro.org>)
[RFC/PoC PATCH 3/3] arm64: enable ROP protection by clearing SP bit #55 across function returns (Ard Biesheuvel <ard.biesheuvel@...aro.org>)

August 6 (14 messages)

Re: [RFC/PoC PATCH 0/3] arm64: basic ROP mitigation (Florian Weimer <fweimer@...hat.com>)
Re: [RFC/PoC PATCH 0/3] arm64: basic ROP mitigation (Ard Biesheuvel <ard.biesheuvel@...aro.org>)
Re: [RFC/PoC PATCH 0/3] arm64: basic ROP mitigation (Robin Murphy <robin.murphy@....com>)
Re: [RFC/PoC PATCH 0/3] arm64: basic ROP mitigation (Ard Biesheuvel <ard.biesheuvel@...aro.org>)
Re: [RFC/PoC PATCH 0/3] arm64: basic ROP mitigation (Ard Biesheuvel <ard.biesheuvel@...aro.org>)
Re: [RFC/PoC PATCH 0/3] arm64: basic ROP mitigation (Robin Murphy <robin.murphy@....com>)
Re: [RFC/PoC PATCH 0/3] arm64: basic ROP mitigation (Ard Biesheuvel <ard.biesheuvel@...aro.org>)
Re: [RFC/PoC PATCH 0/3] arm64: basic ROP mitigation (Ard Biesheuvel <ard.biesheuvel@...aro.org>)
Re: [RFC/PoC PATCH 0/3] arm64: basic ROP mitigation (Robin Murphy <robin.murphy@....com>)
Re: [RFC/PoC PATCH 0/3] arm64: basic ROP mitigation (Kees Cook <keescook@...omium.org>)
Re: [RFC/PoC PATCH 0/3] arm64: basic ROP mitigation (Ard Biesheuvel <ard.biesheuvel@...aro.org>)
Re: [RFC/PoC PATCH 0/3] arm64: basic ROP mitigation (Kees Cook <keescook@...omium.org>)
Re: [RFC/PoC PATCH 0/3] arm64: basic ROP mitigation (Ard Biesheuvel <ard.biesheuvel@...aro.org>)
Re: [PATCH v2 14/19] [media] uvcvideo: prevent bounds-check bypass via speculative execution (Laurent Pinchart <laurent.pinchart@...asonboard.com>)

August 7 (13 messages)

Re: [RFC PATCH 1/2] x86: WARN() when uaccess helpers fault on kernel addresses (Kees Cook <keescook@...omium.org>)
Re: [RFC PATCH 1/2] x86: WARN() when uaccess helpers fault on kernel addresses (Andy Lutomirski <luto@...capital.net>)
Re: [RFC/PoC PATCH 0/3] arm64: basic ROP mitigation (Ard Biesheuvel <ard.biesheuvel@...aro.org>)
Re: [RFC PATCH 1/2] x86: WARN() when uaccess helpers fault on kernel addresses (Ingo Molnar <mingo@...nel.org>)
Re: [RFC PATCH 1/2] x86: WARN() when uaccess helpers fault on kernel addresses (Dmitry Vyukov <dvyukov@...gle.com>)
[RFC PATCH 1/2] x86: WARN() when uaccess helpers fault on kernel addresses (Jann Horn <jannh@...gle.com>)
[RFC PATCH 2/2] lkdtm: test copy_to_user() on bad kernel pointer under KERNEL_DS (Jann Horn <jannh@...gle.com>)
Re: [RFC/PoC PATCH 0/3] arm64: basic ROP mitigation (Mark Brand <markbrand@...gle.com>)
Re: [RFC PATCH 1/2] x86: WARN() when uaccess helpers fault on kernel addresses (Andy Lutomirski <luto@...capital.net>)
Re: [PATCH V2] riscv: Convert uses of REG_FMT to %p (Petr Mladek <pmladek@...e.com>)
Re: [PATCH V2] riscv: Convert uses of REG_FMT to %p (Kees Cook <keescook@...omium.org>)
Re: [RFC PATCH 1/2] x86: WARN() when uaccess helpers fault on kernel addresses (Jann Horn <jannh@...gle.com>)
Re: [RFC PATCH 1/2] x86: WARN() when uaccess helpers fault on kernel addresses (Andy Lutomirski <luto@...capital.net>)

August 8 (2 messages)

Re: [RFC/PoC PATCH 0/3] arm64: basic ROP mitigation (Mark Brand <markbrand@...gle.com>)
Re: [RFC/PoC PATCH 0/3] arm64: basic ROP mitigation (Kees Cook <keescook@...omium.org>)

August 13 (1 message)

Re: [RFC/PoC PATCH 0/3] arm64: basic ROP mitigation (Ard Biesheuvel <ard.biesheuvel@...aro.org>)

August 15 (4 messages)

[PATCH v3 0/3] KASLR feature to randomize each loadable module (Rick Edgecombe <rick.p.edgecombe@...el.com>)
[PATCH v3 1/3] vmalloc: Add __vmalloc_node_try_addr function (Rick Edgecombe <rick.p.edgecombe@...el.com>)
[PATCH v3 2/3] x86/modules: Increase randomization for modules (Rick Edgecombe <rick.p.edgecombe@...el.com>)
[PATCH v3 3/3] vmalloc: Add debugfs modfraginfo (Rick Edgecombe <rick.p.edgecombe@...el.com>)

August 16 (19 messages)

Re: [PATCH v3 1/3] vmalloc: Add __vmalloc_node_try_addr function (kbuild test robot <lkp@...el.com>)
Re: [PATCH v3 2/3] x86/modules: Increase randomization for modules (kbuild test robot <lkp@...el.com>)
[PATCH RFC 0/5] LSM: Add and use a hook for side-channel safety checks (Casey Schaufler <casey.schaufler@...el.com>)
[PATCH RFC 1/5] LSM: Introduce a hook for side-channel danger (Casey Schaufler <casey.schaufler@...el.com>)
[PATCH RFC 2/5] X86: Support LSM determination of side-channel vulnerability (Casey Schaufler <casey.schaufler@...el.com>)
[PATCH RFC 3/5] LSM: Security module checking for side-channel dangers (Casey Schaufler <casey.schaufler@...el.com>)
[PATCH RFC 5/5] SELinux: Support SELinux determination of side-channel vulnerability (Casey Schaufler <casey.schaufler@...el.com>)
[PATCH RFC 4/5] Smack: Support determination of side-channel vulnerability (Casey Schaufler <casey.schaufler@...el.com>)
Re: [PATCH RFC 2/5] X86: Support LSM determination of side-channel vulnerability (Jann Horn <jannh@...gle.com>)
Re: [PATCH RFC 3/5] LSM: Security module checking for side-channel dangers (Jann Horn <jannh@...gle.com>)
Re: [PATCH RFC 5/5] SELinux: Support SELinux determination of side-channel vulnerability (Jann Horn <jannh@...gle.com>)
[PATCH v15 0/7] Introduce the STACKLEAK feature and a test for it (Alexander Popov <alex.popov@...ux.com>)
[PATCH v15 1/7] x86/entry: Add STACKLEAK erasing the kernel stack at the end of syscalls (Alexander Popov <alex.popov@...ux.com>)
[PATCH v15 2/7] gcc-plugins: Add STACKLEAK plugin for tracking the kernel stack (Alexander Popov <alex.popov@...ux.com>)
[PATCH v15 3/7] lkdtm: Add a test for STACKLEAK (Alexander Popov <alex.popov@...ux.com>)
[PATCH v15 4/7] fs/proc: Show STACKLEAK metrics in the /proc file system (Alexander Popov <alex.popov@...ux.com>)
[PATCH v15 6/7] stackleak: Allow runtime disabling of kernel stack erasing (Alexander Popov <alex.popov@...ux.com>)
[PATCH v15 7/7] arm64: Drop unneeded stackleak_check_alloca() (Alexander Popov <alex.popov@...ux.com>)
[PATCH v15 5/7] doc: self-protection: Add information about STACKLEAK feature (Alexander Popov <alex.popov@...ux.com>)

August 17 (9 messages)

Re: [PATCH v15 7/7] arm64: Drop unneeded stackleak_check_alloca() (Will Deacon <will.deacon@....com>)
[PATCH RFC v2 0/5] LSM: Add and use a hook for side-channel safety checks (Casey Schaufler <casey.schaufler@...el.com>)
[PATCH RFC v2 1/5] LSM: Introduce a hook for side-channel danger (Casey Schaufler <casey.schaufler@...el.com>)
[PATCH RFC v2 2/5] X86: Support LSM determination of side-channel vulnerability (Casey Schaufler <casey.schaufler@...el.com>)
[PATCH RFC v2 4/5] Smack: Support determination of side-channel vulnerability (Casey Schaufler <casey.schaufler@...el.com>)
[PATCH RFC v2 3/5] LSM: Security module checking for side-channel dangers (Casey Schaufler <casey.schaufler@...el.com>)
[PATCH RFC v2 5/5] SELinux: Support SELinux determination of side-channel vulnerability (Casey Schaufler <casey.schaufler@...el.com>)
Re: [PATCH RFC v2 3/5] LSM: Security module checking for side-channel dangers (Jann Horn <jannh@...gle.com>)
Re: [PATCH RFC v2 2/5] X86: Support LSM determination of side-channel vulnerability (Jann Horn <jannh@...gle.com>)

August 18 (1 message)

Re: [RFC/PoC PATCH 0/3] arm64: basic ROP mitigation (Laura Abbott <labbott@...hat.com>)

August 20 (13 messages)

Re: [RFC/PoC PATCH 0/3] arm64: basic ROP mitigation (Ard Biesheuvel <ard.biesheuvel@...aro.org>)
RE: [PATCH RFC v2 2/5] X86: Support LSM determination of side-channel vulnerability ("Schaufler, Casey" <casey.schaufler@...el.com>)
RE: [PATCH RFC v2 3/5] LSM: Security module checking for side-channel dangers ("Schaufler, Casey" <casey.schaufler@...el.com>)
RE: [PATCH RFC v2 5/5] SELinux: Support SELinux determination of side-channel vulnerability ("Schaufler, Casey" <casey.schaufler@...el.com>)
RE: [PATCH RFC v2 5/5] SELinux: Support SELinux determination of side-channel vulnerability ("Schaufler, Casey" <casey.schaufler@...el.com>)
Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU) (Linus Torvalds <torvalds@...ux-foundation…)
Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU) (Kees Cook <keescook@...gle.com>)
Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU) (Linus Torvalds <torvalds@...ux-foundation…)
Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU) (Tycho Andersen <tycho@...ho.ws>)
Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU) (Dave Hansen <dave.hansen@...el.com>)
Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU) (Dave Hansen <dave.hansen@...el.com>)
Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU) (David Woodhouse <dwmw2@...radead.org>)
Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU) (Linus Torvalds <torvalds@...ux-foundation…)

August 21 (17 messages)

[PATCH RFC v3 0/5] LSM: Add and use a hook for side-channel safety checks (Casey Schaufler <casey.schaufler@...el.com>)
[PATCH v3 1/5] LSM: Introduce a hook for side-channel danger (Casey Schaufler <casey.schaufler@...el.com>)
[PATCH v3 3/5] LSM: Security module checking for side-channel dangers (Casey Schaufler <casey.schaufler@...el.com>)
[PATCH v3 2/5] X86: Support LSM determination of side-channel (Casey Schaufler <casey.schaufler@...el.com>)
[PATCH v3 5/5] SELinux: Support SELinux determination of side-channel (Casey Schaufler <casey.schaufler@...el.com>)
[PATCH v3 4/5] Smack: Support determination of side-channel (Casey Schaufler <casey.schaufler@...el.com>)
Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU) (Konrad Rzeszutek Wilk <konrad.wilk@...cle.com…)
Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU) (David Woodhouse <dwmw2@...radead.org>)
Re: [PATCH RFC v2 2/5] X86: Support LSM determination of side-channel vulnerability (Jann Horn <jannh@...gle.com>)
Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU) (Liran Alon <liran.alon@...cle.com>)
Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU) (David Woodhouse <dwmw2@...radead.org>)
Re: [PATCH v15 0/7] Introduce the STACKLEAK feature and a test for it (Laura Abbott <labbott@...hat.com>)
RE: [PATCH RFC v2 2/5] X86: Support LSM determination of side-channel vulnerability ("Schaufler, Casey" <casey.schaufler@...el.com>)
Re: [PATCH v3 3/5] LSM: Security module checking for side-channel dangers (Jann Horn <jannh@...gle.com>)
Re: [PATCH RFC v2 2/5] X86: Support LSM determination of side-channel vulnerability (Jann Horn <jannh@...gle.com>)
Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU) (Liran Alon <liran.alon@...cle.com>)
RE: [PATCH v3 3/5] LSM: Security module checking for side-channel dangers ("Schaufler, Casey" <casey.schaufler@...el.com>)

August 22 (5 messages)

Re: [PATCH v3 3/5] LSM: Security module checking for side-channel dangers (Jann Horn <jannh@...gle.com>)
RE: [PATCH v3 3/5] LSM: Security module checking for side-channel dangers ("Schaufler, Casey" <casey.schaufler@...el.com>)
Re: [PATCH v3 3/5] LSM: Security module checking for side-channel dangers (Jann Horn <jannh@...gle.com>)
RE: [PATCH v3 3/5] LSM: Security module checking for side-channel dangers ("Schaufler, Casey" <casey.schaufler@...el.com>)
Re: [RFC PATCH 1/2] x86: WARN() when uaccess helpers fault on kernel addresses (Jann Horn <jannh@...gle.com>)

August 23 (3 messages)

Re: [RFC PATCH 1/2] x86: WARN() when uaccess helpers fault on kernel addresses (Andy Lutomirski <luto@...capital.net>)
Re: [RFC PATCH 1/2] x86: WARN() when uaccess helpers fault on kernel addresses (Jann Horn <jannh@...gle.com>)
Re: [RFC PATCH 1/2] x86: WARN() when uaccess helpers fault on kernel addresses (Andy Lutomirski <luto@...capital.net>)

August 24 (7 messages)

[PATCH v4 0/5] LSM: Add and use a hook for side-channel safety checks (Casey Schaufler <casey.schaufler@...el.com>)
[PATCH v4 3/5] LSM: Security module checking for side-channel dangers (Casey Schaufler <casey.schaufler@...el.com>)
[PATCH v4 2/5] X86: Support LSM determination of side-channel (Casey Schaufler <casey.schaufler@...el.com>)
[PATCH v4 1/5] LSM: Introduce a hook for side-channel danger (Casey Schaufler <casey.schaufler@...el.com>)
[PATCH v4 4/5] Smack: Support determination of side-channel (Casey Schaufler <casey.schaufler@...el.com>)
[PATCH v4 5/5] SELinux: Support SELinux determination of side-channel (Casey Schaufler <casey.schaufler@...el.com>)
Re: [PATCH v4 3/5] LSM: Security module checking for side-channel dangers (Jann Horn <jannh@...gle.com>)

August 27 (14 messages)

Re: [PATCH v2 3/7] x86: stop calling fixup_exception() from kprobe_fault_handler() (Andy Lutomirski <luto@...nel.org>)
Re: [PATCH v2 5/7] x86: plumb error code and fault address through to fault handlers (Andy Lutomirski <luto@...nel.org>)
Re: [PATCH v2 3/7] x86: stop calling fixup_exception() from kprobe_fault_handler() (Jann Horn <jannh@...gle.com>)
Re: [PATCH v2 3/7] x86: stop calling fixup_exception() from kprobe_fault_handler() (Andy Lutomirski <luto@...nel.org>)
Re: [PATCH v2 5/7] x86: plumb error code and fault address through to fault handlers (Jann Horn <jannh@...gle.com>)
[PATCH v2 0/7] x86: BUG() on #GP / kernel #PF in uaccess (Jann Horn <jannh@...gle.com>)
[PATCH v2 1/7] x86: refactor kprobes_fault() like kprobe_exceptions_notify() (Jann Horn <jannh@...gle.com>)
[PATCH v2 2/7] x86: inline kprobe_exceptions_notify() into do_general_protection() (Jann Horn <jannh@...gle.com>)
[PATCH v2 3/7] x86: stop calling fixup_exception() from kprobe_fault_handler() (Jann Horn <jannh@...gle.com>)
[PATCH v2 4/7] x86: introduce _ASM_EXTABLE_UA for uaccess fixups (Jann Horn <jannh@...gle.com>)
[PATCH v2 5/7] x86: plumb error code and fault address through to fault handlers (Jann Horn <jannh@...gle.com>)
[PATCH v2 6/7] x86: BUG() when uaccess helpers fault on kernel addresses (Jann Horn <jannh@...gle.com>)
[PATCH v2 7/7] lkdtm: test copy_to_user() on bad kernel pointer under KERNEL_DS (Jann Horn <jannh@...gle.com>)
Re: [PATCH v2 7/7] lkdtm: test copy_to_user() on bad kernel pointer under KERNEL_DS (Kees Cook <keescook@...omium.org>)

August 28 (13 messages)

Re: [PATCH v2 6/7] x86: BUG() when uaccess helpers fault on kernel addresses (Jann Horn <jannh@...gle.com>)
Re: [PATCH v2 3/7] x86: stop calling fixup_exception() from kprobe_fault_handler() (Masami Hiramatsu <mhiramat@...nel.org>)
Re: [PATCH v2 1/7] x86: refactor kprobes_fault() like kprobe_exceptions_notify() (Borislav Petkov <bp@...en8.de>)
[PATCH v3 0/7] x86: BUG() on #GP / kernel #PF in uaccess (Jann Horn <jannh@...gle.com>)
[PATCH v3 1/7] x86: refactor kprobes_fault() like kprobe_exceptions_notify() (Jann Horn <jannh@...gle.com>)
[PATCH v3 2/7] x86: inline kprobe_exceptions_notify() into do_general_protection() (Jann Horn <jannh@...gle.com>)
[PATCH v3 3/7] x86: stop calling fixup_exception() from kprobe_fault_handler() (Jann Horn <jannh@...gle.com>)
[PATCH v3 4/7] x86: introduce _ASM_EXTABLE_UA for uaccess fixups (Jann Horn <jannh@...gle.com>)
[PATCH v3 5/7] x86: plumb error code and fault address through to fault handlers (Jann Horn <jannh@...gle.com>)
[PATCH v3 6/7] x86: BUG() when uaccess helpers fault on kernel addresses (Jann Horn <jannh@...gle.com>)
[PATCH v3 7/7] lkdtm: test copy_to_user() on bad kernel pointer under KERNEL_DS (Jann Horn <jannh@...gle.com>)
Re: [PATCH v3 0/7] x86: BUG() on #GP / kernel #PF in uaccess (Kees Cook <keescook@...omium.org>)
Re: [PATCH v3 1/7] x86: refactor kprobes_fault() like kprobe_exceptions_notify() (Masami Hiramatsu <mhiramat@...nel.org>)

August 29 (5 messages)

Re: [PATCH v3 2/7] x86: inline kprobe_exceptions_notify() into do_general_protection() (Masami Hiramatsu <mhiramat@...nel.org>)
[PATCH v4 0/3] KASLR feature to randomize each loadable module (Rick Edgecombe <rick.p.edgecombe@...el.com>)
[PATCH v4 1/3] vmalloc: Add __vmalloc_node_try_addr function (Rick Edgecombe <rick.p.edgecombe@...el.com>)
[PATCH v4 2/3] x86/modules: Increase randomization for modules (Rick Edgecombe <rick.p.edgecombe@...el.com>)
[PATCH v4 3/3] vmalloc: Add debugfs modfraginfo (Rick Edgecombe <rick.p.edgecombe@...el.com>)

August 30 (2 messages)

Re: [PATCH v4 0/3] KASLR feature to randomize each loadable module (Alexei Starovoitov <alexei.starovoitov@...il.com>)
Re: [PATCH v4 0/3] KASLR feature to randomize each loadable module ("Edgecombe, Rick P" <rick.p.edgecombe@...el.com>)

August 31 (4 messages)

Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU) (Julian Stecklina <jsteckli@...zon.de>)
Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU) (James Bottomley <James.Bottomley@...senPa…)
Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU) (Tycho Andersen <tycho@...ho.ws>)
"Hardened" tree on kernel.org? (Konstantin Ryabitsev <konstantin@...uxfoundation.org>)

150 messages

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.