kernel-hardening mailing list - 2016/08

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

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

kernel-hardening mailing list - 2016/08

Mon	Tue	Wed	Thu	Fri	Sat	Sun
¹ 12	² 32	³ 28	⁴ 19	⁵ 5	⁶ 1	⁷ 3
⁸ 10	⁹ 29	¹⁰ 24	¹¹ 11	¹² 22	¹³ 1	¹⁴ 2
¹⁵ 24	¹⁶ 12	¹⁷ 27	¹⁸ 6	¹⁹ 4	²⁰	²¹
²² 3	²³ 1	²⁴	²⁵ 18	²⁶ 11	²⁷ 18	²⁸ 3
²⁹ 2	³⁰ 16	³¹ 6

Messages by day:

August 1 (12 messages)

Re: Re: [PATCH] [RFC] Introduce mmap randomization (Daniel Micay <danielmicay@...il.com>)
RE: [RFC] [PATCH 1/5] path_fchdir and path_fhandle LSM hooks ("Reshetova, Elena" <elena.reshetova@...el.com>)
RE: [RFC] [PATCH 4/5] invoke path_chroot() LSM hook on mntns_install() ("Reshetova, Elena" <elena.reshetova@...el.com>)
Linker segfault on powerpc when CONFIG_LKDTM=y (was Re: [PATCH 3/5] lkdtm: add function for testing .rodata section) (Michael Ellerman <mpe@...erman.id.au>)
[PATCH v1 0/2] x86/power/64: Make KASLR memory randomization compatible with hibernation (Thomas Garnier <thgarnie@...gle.com>)
[PATCH v1 1/2] x86/power/64: Support unaligned addresses for temporary mapping (Thomas Garnier <thgarnie@...gle.com>)
[PATCH v1 2/2] x86/power/64: Fix __PAGE_OFFSET usage on restore (Thomas Garnier <thgarnie@...gle.com>)
Re: [PATCH] x86/mm: Enable KASLR for vmemmap memory region (x86_64) (Thomas Garnier <thgarnie@...gle.com>)
Re: Linker segfault on powerpc when CONFIG_LKDTM=y (was Re: [PATCH 3/5] lkdtm: add function for testing .rodata section) (Kees Cook <keescook@...omium.org>)
Re: [PATCH v2 1/7] random: Simplify API for random address requests (Kees Cook <keescook@...omium.org>)
Re: [PATCH v2 1/7] random: Simplify API for random address requests (Jason Cooper <jason@...edaemon.net>)
Re: [PATCH v1 0/2] x86/power/64: Make KASLR memory randomization compatible with hibernation ("Rafael J. Wysocki" <rjw@...ysocki.net>)

August 2 (32 messages)

Re: [PATCH v1 1/2] x86/power/64: Support unaligned addresses for temporary mapping ("Rafael J. Wysocki" <rjw@...ysocki.net>)
Re: [PATCH v1 2/2] x86/power/64: Fix __PAGE_OFFSET usage on restore ("Rafael J. Wysocki" <rjw@...ysocki.net>)
Re: [PATCH v1 0/2] x86/power/64: Make KASLR memory randomization compatible with hibernation ("Rafael J. Wysocki" <rjw@...ysocki.net>)
Re: Re: Linker segfault on powerpc when CONFIG_LKDTM=y (was Re: [PATCH 3/5] lkdtm: add function for testing .rodata sectio… (Michael Ellerman <mpe@...erman.id.au>)
Re: Re: [PATCH v2 1/7] random: Simplify API for random address requests (Michael Ellerman <mpe@...erman.id.au>)
Re: [PATCH] x86/mm: Enable KASLR for vmemmap memory region (x86_64) (Ingo Molnar <mingo@...nel.org>)
Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open (Peter Zijlstra <peterz@...radead.org>)
Re: [PATCH 2/2] security, perf: Add config option to restrict perf_event_open (Peter Zijlstra <peterz@...radead.org>)
Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open (Arnaldo Carvalho de Melo <acme@...nel.org>)
Re: Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open (Daniel Micay <danielmicay@...il.com>)
Re: Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open (Daniel Micay <danielmicay@...il.com>)
Re: [PATCH] x86/mm: Enable KASLR for vmemmap memory region (x86_64) (Thomas Garnier <thgarnie@...gle.com>)
Re: [PATCH v1 2/2] x86/power/64: Fix __PAGE_OFFSET usage on restore (Thomas Garnier <thgarnie@...gle.com>)
Re: Re: [PATCH 2/2] security, perf: Add config option to restrict perf_event_open (Kees Cook <keescook@...omium.org>)
RE: [PATCH] [RFC] Introduce mmap randomization ("Roberts, William C" <william.c.roberts@...el.com>)
Re: [PATCH] [RFC] Introduce mmap randomization (Nick Kralevich <nnk@...gle.com>)
RE: [PATCH] [RFC] Introduce mmap randomization ("Roberts, William C" <william.c.roberts@...el.com>)
RE: [PATCH] [RFC] Introduce mmap randomization ("Roberts, William C" <william.c.roberts@...el.com>)
Re: [PATCH v1 1/2] x86/power/64: Support unaligned addresses for temporary mapping (Yinghai Lu <yinghai@...nel.org>)
Re: [PATCH v1 1/2] x86/power/64: Support unaligned addresses for temporary mapping (Thomas Garnier <thgarnie@...gle.com>)
Re: [PATCH v1 1/2] x86/power/64: Support unaligned addresses for temporary mapping (Yinghai Lu <yinghai@...nel.org>)
Re: Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open (Kees Cook <keescook@...omium.org>)
Re: Re: Linker segfault on powerpc when CONFIG_LKDTM=y (was Re: [PATCH 3/5] lkdtm: add function for testing .rodata section) (Kees Cook <keescook@...omium.org>)
Re: [PATCH v1 1/2] x86/power/64: Support unaligned addresses for temporary mapping (Yinghai Lu <yinghai@...nel.org>)
Re: Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open (Peter Zijlstra <peterz@...radead.org>)
Re: [PATCH v1 2/2] x86/power/64: Fix __PAGE_OFFSET usage on restore ("Rafael J. Wysocki" <rafael@...nel.org>)
Re: Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open (Kees Cook <keescook@...omium.org>)
Re: [PATCH v1 2/2] x86/power/64: Fix __PAGE_OFFSET usage on restore (Thomas Garnier <thgarnie@...gle.com>)
Re: Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open (Jeffrey Vander Stoep <jeffv@...gle.com>)
Re: [PATCH v1 2/2] x86/power/64: Fix __PAGE_OFFSET usage on restore ("Rafael J. Wysocki" <rafael@...nel.org>)
Re: Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open (Jeffrey Vander Stoep <jeffv@...gle.com>)
[PATCH] x86/power/64: Do not refer to __PAGE_OFFSET from assembly code ("Rafael J. Wysocki" <rjw@...ysocki.net>)

August 3 (28 messages)

Re: Re: Linker segfault on powerpc when CONFIG_LKDTM=y (was Re: [PATCH 3/5] lkdtm: add function for testing .rodata sectio… (Michael Ellerman <mpe@...erman.id.au>)
[PATCH] lkdtm: Mark lkdtm_rodata_do_nothing() notrace (Michael Ellerman <mpe@...erman.id.au>)
Re: [RFC] [PATCH 0/5] Hardchroot LSM + additional hooks (James Morris <jmorris@...ei.org>)
Re: Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open (Ingo Molnar <mingo@...nel.org>)
Re: Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open (Daniel Micay <danielmicay@...il.com>)
Re: Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open (Daniel Micay <danielmicay@...il.com>)
Re: Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open (Peter Zijlstra <peterz@...radead.org>)
Re: Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open (Peter Zijlstra <peterz@...radead.org>)
Re: [PATCH v1 1/2] x86/power/64: Support unaligned addresses for temporary mapping (Thomas Garnier <thgarnie@...gle.com>)
RE: Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open ("Schaufler, Casey" <casey.schaufler@...el.com>)
Re: Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open (ebiederm@...ssion.com (Eric W. Biederman))
RE: [PATCH] [RFC] Introduce mmap randomization ("Roberts, William C" <william.c.roberts@...el.com>)
Re: Re: [PATCH v2 1/7] random: Simplify API for random address requests (Jason Cooper <jason@...edaemon.net>)
Re: Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open (Kees Cook <keescook@...omium.org>)
Re: [PATCH] lkdtm: Mark lkdtm_rodata_do_nothing() notrace (Kees Cook <keescook@...omium.org>)
[PATCH v2] x86/power/64: Support unaligned addresses for temporary mapping (Yinghai Lu <yinghai@...nel.org>)
Re: Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open (Daniel Micay <danielmicay@...il.com>)
Re: [PATCH v2] x86/power/64: Support unaligned addresses for temporary mapping ("Rafael J. Wysocki" <rafael@...nel.org>)
Re: Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open (Peter Zijlstra <peterz@...radead.org>)
[PATCH v3 0/7] char/random: Simplify random address requests (Jason Cooper <jason@...edaemon.net>)
[PATCH v3 1/7] random: Simplify API for random address requests (Jason Cooper <jason@...edaemon.net>)
[PATCH v3 2/7] x86: Use simpler API for random address requests (Jason Cooper <jason@...edaemon.net>)
[PATCH v3 3/7] ARM: Use simpler API for random address requests (Jason Cooper <jason@...edaemon.net>)
[PATCH v3 4/7] arm64: Use simpler API for random address requests (Jason Cooper <jason@...edaemon.net>)
[PATCH v3 5/7] tile: Use simpler API for random address requests (Jason Cooper <jason@...edaemon.net>)
[PATCH v3 6/7] unicore32: Use simpler API for random address requests (Jason Cooper <jason@...edaemon.net>)
[PATCH v3 7/7] random: Remove unused randomize_range() (Jason Cooper <jason@...edaemon.net>)
Re: [PATCH v3 7/7] random: Remove unused randomize_range() (Andrew Morton <akpm@...ux-foundation.org>)

August 4 (19 messages)

Re: [PATCH v3 7/7] random: Remove unused randomize_range() (Jason Cooper <jason@...edaemon.net>)
Re: [PATCH v3 0/7] char/random: Simplify random address requests (Kees Cook <keescook@...omium.org>)
Re: Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open (ebiederm@...ssion.com (Eric W. Biederman))
Re: Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open (Peter Zijlstra <peterz@...radead.org>)
Re: Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open (Mark Rutland <mark.rutland@....com>)
Re: [PATCH v3 1/7] random: Simplify API for random address requests (Yann Droneaud <ydroneaud@...eya.com>)
Re: Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open (Daniel Micay <danielmicay@...il.com>)
Re: Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open (Peter Zijlstra <peterz@...radead.org>)
Re: Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open (ebiederm@...ssion.com (Eric W. Biederman))
Re: Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open (Peter Zijlstra <peterz@...radead.org>)
Re: Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open (Daniel Micay <danielmicay@...il.com>)
Re: Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open (Peter Zijlstra <peterz@...radead.org>)
Re: Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open (Mark Rutland <mark.rutland@....com>)
Re: Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open (Daniel Micay <danielmicay@...il.com>)
Re: [PATCH] [RFC] Introduce mmap randomization (Daniel Micay <danielmicay@...il.com>)
RE: [PATCH] [RFC] Introduce mmap randomization ("Roberts, William C" <william.c.roberts@...el.com>)
Re: Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open (Mark Rutland <mark.rutland@....com>)
Re: [PATCH] [RFC] Introduce mmap randomization (Daniel Micay <danielmicay@...il.com>)
Re: Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open (Daniel Micay <danielmicay@...il.com>)

August 5 (5 messages)

RE: [RFC] [PATCH 0/5] Hardchroot LSM + additional hooks ("Reshetova, Elena" <elena.reshetova@...el.com>)
Re: [PATCH] x86/power/64: Do not refer to __PAGE_OFFSET from assembly code (Pavel Machek <pavel@...x.de>)
Re: [PATCH] x86/power/64: Do not refer to __PAGE_OFFSET from assembly code ("Rafael J. Wysocki" <rjw@...ysocki.net>)
Re: [PATCH] x86/power/64: Do not refer to __PAGE_OFFSET from assembly code (Thomas Garnier <thgarnie@...gle.com>)
Re: [PATCH] x86/power/64: Do not refer to __PAGE_OFFSET from assembly code ("Rafael J. Wysocki" <rjw@...ysocki.net>)

August 6 (1 message)

Re: [PATCH] x86/power/64: Do not refer to __PAGE_OFFSET from assembly code (Pavel Machek <pavel@...x.de>)

August 7 (3 messages)

Re: [PATCH v2] x86/power/64: Support unaligned addresses for temporary mapping ("Rafael J. Wysocki" <rjw@...ysocki.net>)
Re: [PATCH v2] x86/power/64: Support unaligned addresses for temporary mapping (Yinghai Lu <yinghai@...nel.org>)
Re: [PATCH v2] x86/power/64: Support unaligned addresses for temporary mapping ("Rafael J. Wysocki" <rjw@...ysocki.net>)

August 8 (10 messages)

Re: [PATCH v2] x86/power/64: Support unaligned addresses for temporary mapping (Yinghai Lu <yinghai@...nel.org>)
Re: [PATCH v2] x86/power/64: Support unaligned addresses for temporary mapping (Yinghai Lu <yinghai@...nel.org>)
Re: [PATCH v2] x86/power/64: Support unaligned addresses for temporary mapping ("Rafael J. Wysocki" <rjw@...ysocki.net>)
[Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly ("Rafael J. Wysocki" <rjw@...ysocki.net>)
Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly (Borislav Petkov <bp@...e.de>)
Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly ("Rafael J. Wysocki" <rafael@...nel.org>)
Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly (Thomas Garnier <thgarnie@...gle.com>)
[PATCH v1 1/2] x86/KASLR: Fix physical memory calculation on KASLR memory randomization (Thomas Garnier <thgarnie@...gle.com>)
[PATCH v1 2/2] x86/KASLR: Increase BRK pages for KASLR memory randomization (Thomas Garnier <thgarnie@...gle.com>)
Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly ("Rafael J. Wysocki" <rafael@...nel.org>)

August 9 (29 messages)

Re: [PATCH v1 2/2] x86/KASLR: Increase BRK pages for KASLR memory randomization (Borislav Petkov <bp@...e.de>)
Re: [PATCH v1 2/2] x86/KASLR: Increase BRK pages for KASLR memory randomization ("H. Peter Anvin" <hpa@...or.com>)
Re: [PATCH v1 2/2] x86/KASLR: Increase BRK pages for KASLR memory randomization (Mika Penttilä <mika.penttila@...tfour.com>)
Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly (Borislav Petkov <bp@...e.de>)
Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly (Jiri Kosina <jikos@...nel.org>)
Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly ("Rafael J. Wysocki" <rafael@...nel.org>)
Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly ("Rafael J. Wysocki" <rafael@...nel.org>)
Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly (Jiri Kosina <jikos@...nel.org>)
Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly (Jiri Kosina <jikos@...nel.org>)
Re: [PATCH v1 2/2] x86/KASLR: Increase BRK pages for KASLR memory randomization (Thomas Garnier <thgarnie@...gle.com>)
Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly (Thomas Garnier <thgarnie@...gle.com>)
Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly (Jiri Kosina <jikos@...nel.org>)
[lkp] [x86/KASLR] 20067c4c13: kernel BUG at arch/x86/mm/physaddr.c:26! (kernel test robot <xiaolong.ye@...el.com>)
Re: [PATCH v1 1/2] x86/KASLR: Fix physical memory calculation on KASLR memory randomization (Thomas Garnier <thgarnie@...gle.com>)
Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly ("Rafael J. Wysocki" <rafael@...nel.org>)
Re: [PATCH v1 1/2] x86/KASLR: Fix physical memory calculation on KASLR memory randomization (Joerg Roedel <jroedel@...e.de>)
Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly (Thomas Garnier <thgarnie@...gle.com>)
Re: [PATCH v1 1/2] x86/KASLR: Fix physical memory calculation on KASLR memory randomization (Thomas Garnier <thgarnie@...gle.com>)
[PATCH v2 1/2] x86/KASLR: Fix physical memory calculation on KASLR memory randomization (Thomas Garnier <thgarnie@...gle.com>)
[PATCH v2 2/2] x86/KASLR: Increase BRK pages for KASLR memory randomization (Thomas Garnier <thgarnie@...gle.com>)
[PATCH v3 1/2] x86/KASLR: Fix physical memory calculation on KASLR memory randomization (Thomas Garnier <thgarnie@...gle.com>)
[PATCH v3 2/2] x86/KASLR: Increase BRK pages for KASLR memory randomization (Thomas Garnier <thgarnie@...gle.com>)
Re: [PATCH v2 2/2] x86/KASLR: Increase BRK pages for KASLR memory randomization (Borislav Petkov <bp@...e.de>)
Re: [PATCH v2 2/2] x86/KASLR: Increase BRK pages for KASLR memory randomization (Thomas Garnier <thgarnie@...gle.com>)
[PATCH v4 1/2] x86/KASLR: Fix physical memory calculation on KASLR memory randomization (Thomas Garnier <thgarnie@...gle.com>)
[PATCH v4 2/2] x86/KASLR: Increase BRK pages for KASLR memory randomization (Thomas Garnier <thgarnie@...gle.com>)
Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly (Jiri Kosina <jikos@...nel.org>)
Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly ("Rafael J. Wysocki" <rafael@...nel.org>)
Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly ("Rafael J. Wysocki" <rafael@...nel.org>)

August 10 (24 messages)

Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly ("Rafael J. Wysocki" <rjw@...ysocki.net>)
Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly (Jiri Kosina <jikos@...nel.org>)
Re: [PATCH 2/2] arm: apply more __ro_after_init (Russell King - ARM Linux <linux@...linux.org.uk>)
Re: [PATCH 2/2] arm: apply more __ro_after_init (Arnd Bergmann <arnd@...db.de>)
Re: [PATCH 2/2] arm: apply more __ro_after_init (Russell King - ARM Linux <linux@...linux.org.uk>)
Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly ("Rafael J. Wysocki" <rjw@...ysocki.net>)
Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly (Jiri Kosina <jikos@...nel.org>)
Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly (Thomas Garnier <thgarnie@...gle.com>)
Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly (Jiri Kosina <jikos@...nel.org>)
Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly (Borislav Petkov <bp@...e.de>)
Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly (Thomas Garnier <thgarnie@...gle.com>)
Re: Re: [PATCH 2/2] arm: apply more __ro_after_init (Daniel Micay <danielmicay@...il.com>)
Re: [PATCH 2/2] arm: apply more __ro_after_init (Kees Cook <keescook@...omium.org>)
Re: [PATCH 2/2] arm: apply more __ro_after_init (Arnd Bergmann <arnd@...db.de>)
Re: [PATCH 2/2] arm: apply more __ro_after_init (Arnd Bergmann <arnd@...db.de>)
Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly ("Rafael J. Wysocki" <rafael@...nel.org>)
Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly ("Rafael J. Wysocki" <rafael@...nel.org>)
Re: [PATCH 2/2] arm: apply more __ro_after_init (Kees Cook <keescook@...omium.org>)
Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly (Jiri Kosina <jikos@...nel.org>)
Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly ("Rafael J. Wysocki" <rafael@...nel.org>)
Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly (Jiri Kosina <jikos@...nel.org>)
[PATCH] mm: Add the ram_latent_entropy kernel parameter (Kees Cook <keescook@...omium.org>)
Re: [PATCH 2/2] arm: apply more __ro_after_init (Russell King - ARM Linux <linux@...linux.org.uk>)
Re: [PATCH 2/2] arm: apply more __ro_after_init (Russell King - ARM Linux <linux@...linux.org.uk>)

August 11 (11 messages)

Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly ("Rafael J. Wysocki" <rafael@...nel.org>)
Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly (Thomas Garnier <thgarnie@...gle.com>)
Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly ("Rafael J. Wysocki" <rafael@...nel.org>)
Re: [PATCH] mm: Add the ram_latent_entropy kernel parameter (Dave Hansen <dave.hansen@...el.com>)
Re: [PATCH 2/2] arm: apply more __ro_after_init (Arnd Bergmann <arnd@...db.de>)
Re: [PATCH 2/2] arm: apply more __ro_after_init (Arnd Bergmann <arnd@...db.de>)
Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly (Thomas Garnier <thgarnie@...gle.com>)
Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly ("Rafael J. Wysocki" <rjw@...ysocki.net>)
Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly (Thomas Garnier <thgarnie@...gle.com>)
[PATCH v1] x86/power/64: Restore processor state before using per-cpu variables (Thomas Garnier <thgarnie@...gle.com>)
Re: [PATCH 2/2] arm: apply more __ro_after_init (Kees Cook <keescook@...omium.org>)

August 12 (22 messages)

Re: [PATCH] mm: Add the ram_latent_entropy kernel parameter (Balbir Singh <bsingharora@...il.com>)
Re: [PATCH v1] x86/power/64: Restore processor state before using per-cpu variables (Borislav Petkov <bp@...e.de>)
Re: [PATCH v1] x86/power/64: Restore processor state before using per-cpu variables (Jiri Kosina <jikos@...nel.org>)
Re: [PATCH v1] x86/power/64: Restore processor state before using per-cpu variables (Pavel Machek <pavel@...x.de>)
Re: [PATCH v1] x86/power/64: Restore processor state before using per-cpu variables (Jiri Kosina <jikos@...nel.org>)
Re: [PATCH v1] x86/power/64: Restore processor state before using per-cpu variables ("Rafael J. Wysocki" <rafael@...nel.org>)
Re: [PATCH 2/2] arm: apply more __ro_after_init (Daniel Thompson <daniel.thompson@...aro.org>)
[PATCH 1/7] arm64: Factor out PAN enabling/disabling into separate uaccess_* macros (Catalin Marinas <catalin.marinas@....com>)
[PATCH 3/7] arm64: Introduce uaccess_{disable,enable} functionality based on TTBR0_EL1 (Catalin Marinas <catalin.marinas@....com>)
[PATCH 4/7] arm64: Disable TTBR0_EL1 during normal kernel execution (Catalin Marinas <catalin.marinas@....com>)
[PATCH 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching (Catalin Marinas <catalin.marinas@....com>)
[PATCH 2/7] arm64: Factor out TTBR0_EL1 setting into a specific asm macro (Catalin Marinas <catalin.marinas@....com>)
[PATCH 5/7] arm64: Handle faults caused by inadvertent user access with PAN enabled (Catalin Marinas <catalin.marinas@....com>)
[PATCH 6/7] arm64: xen: Enable user access before a privcmd hvc call (Catalin Marinas <catalin.marinas@....com>)
[PATCH 7/7] arm64: Enable CONFIG_ARM64_TTBR0_PAN (Catalin Marinas <catalin.marinas@....com>)
Re: [PATCH v1] x86/power/64: Restore processor state before using per-cpu variables (Thomas Garnier <thgarnie@...gle.com>)
Re: [PATCH v1] x86/power/64: Restore processor state before using per-cpu variables (Thomas Garnier <thgarnie@...gle.com>)
Re: [PATCH 2/2] arm: apply more __ro_after_init (Russell King - ARM Linux <linux@...linux.org.uk>)
Re: [PATCH v1] x86/power/64: Restore processor state before using per-cpu variables (Borislav Petkov <bp@...e.de>)
[PATCH v2] x86/power/64: Restore processor state before using per-cpu variables (Thomas Garnier <thgarnie@...gle.com>)
Re: [PATCH 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching (Kees Cook <keescook@...omium.org>)
Re: [PATCH 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching (Catalin Marinas <catalin.marinas@....com>)

August 13 (1 message)

Re: [PATCH 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching (Ard Biesheuvel <ard.biesheuvel@...aro.org>)

August 14 (2 messages)

Re: [PATCH] [RFC] Introduce mmap randomization (Pavel Machek <pavel@....cz>)
Re: [PATCH] [RFC] Introduce mmap randomization (Pavel Machek 1 <pavel@...x.de>)

August 15 (24 messages)

Re: [PATCH 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching (Catalin Marinas <catalin.marinas@....com>)
Re: [PATCH 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching (Mark Rutland <mark.rutland@....com>)
Re: [PATCH 6/7] arm64: xen: Enable user access before a privcmd hvc call (Julien Grall <julien.grall@....com>)
Re: [PATCH 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching (Ard Biesheuvel <ard.biesheuvel@...aro.org>)
Re: [PATCH 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching (Mark Rutland <mark.rutland@....com>)
Re: [PATCH 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching (Will Deacon <will.deacon@....com>)
Re: [PATCH 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching (Will Deacon <will.deacon@....com>)
Re: [PATCH 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching (Mark Rutland <mark.rutland@....com>)
Re: [PATCH 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching (Ard Biesheuvel <ard.biesheuvel@...aro.org>)
Re: [PATCH 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching (Will Deacon <will.deacon@....com>)
Re: [PATCH 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching (Will Deacon <will.deacon@....com>)
Re: [PATCH 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching (Ard Biesheuvel <ard.biesheuvel@...aro.org>)
Re: [PATCH 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching (Will Deacon <will.deacon@....com>)
Re: [PATCH 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching (Ard Biesheuvel <ard.biesheuvel@...aro.org>)
Re: [PATCH 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching (Mark Rutland <mark.rutland@....com>)
Re: [PATCH 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching (Catalin Marinas <catalin.marinas@....com>)
Re: [PATCH 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching (Ard Biesheuvel <ard.biesheuvel@...aro.org>)
Re: [PATCH 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching (Will Deacon <will.deacon@....com>)
Re: [PATCH 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching (Will Deacon <will.deacon@....com>)
Re: [PATCH 4/7] arm64: Disable TTBR0_EL1 during normal kernel execution (Mark Rutland <mark.rutland@....com>)
Re: [PATCH 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching (Catalin Marinas <catalin.marinas@....com>)
Re: [PATCH 4/7] arm64: Disable TTBR0_EL1 during normal kernel execution (Catalin Marinas <catalin.marinas@....com>)
Re: [PATCH 6/7] arm64: xen: Enable user access before a privcmd hvc call (Stefano Stabellini <sstabellini@...nel.org>)
Re: [PATCH 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching (Ard Biesheuvel <ard.biesheuvel@...aro.org>)

August 16 (12 messages)

[PATCH 3/5] list: Split list_del() debug checking into separate function (Kees Cook <keescook@...omium.org>)
[PATCH 5/5] lkdtm: Add tests for struct list corruption (Kees Cook <keescook@...omium.org>)
[PATCH 1/5] list: Split list_add() debug checking into separate function (Kees Cook <keescook@...omium.org>)
[PATCH 2/5] rculist: Consolidate DEBUG_LIST for list_add_rcu() (Kees Cook <keescook@...omium.org>)
[PATCH 4/5] bug: Provide toggle for BUG on data corruption (Kees Cook <keescook@...omium.org>)
[PATCH 0/5] bug: Provide toggle for BUG on data corruption (Kees Cook <keescook@...omium.org>)
Re: [PATCH 4/5] bug: Provide toggle for BUG on data corruption (Kees Cook <keescook@...omium.org>)
Re: [PATCH 4/5] bug: Provide toggle for BUG on data corruption (Laura Abbott <labbott@...hat.com>)
Re: [PATCH 4/5] bug: Provide toggle for BUG on data corruption (Steven Rostedt <rostedt@...dmis.org>)
Re: [PATCH 4/5] bug: Provide toggle for BUG on data corruption (Steven Rostedt <rostedt@...dmis.org>)
Re: [PATCH 4/5] bug: Provide toggle for BUG on data corruption (Kees Cook <keescook@...omium.org>)
Re: [PATCH 4/5] bug: Provide toggle for BUG on data corruption (Kees Cook <keescook@...omium.org>)

August 17 (27 messages)

Re: [PATCH 4/5] bug: Provide toggle for BUG on data corruption (Kees Cook <keescook@...omium.org>)
[PATCH v2 1/5] list: Split list_add() debug checking into separate function (Kees Cook <keescook@...omium.org>)
[PATCH v2 2/5] rculist: Consolidate DEBUG_LIST for list_add_rcu() (Kees Cook <keescook@...omium.org>)
[PATCH v2 0/5] bug: Provide toggle for BUG on data corruption (Kees Cook <keescook@...omium.org>)
[PATCH v2 3/5] list: Split list_del() debug checking into separate function (Kees Cook <keescook@...omium.org>)
[PATCH v2 4/5] bug: Provide toggle for BUG on data corruption (Kees Cook <keescook@...omium.org>)
[PATCH v2 5/5] lkdtm: Add tests for struct list corruption (Kees Cook <keescook@...omium.org>)
Re: [PATCH v2 4/5] bug: Provide toggle for BUG on data corruption (Joe Perches <joe@...ches.com>)
Re: [PATCH v2 0/5] bug: Provide toggle for BUG on data corruption (Kees Cook <keescook@...omium.org>)
Re: [PATCH v2 4/5] bug: Provide toggle for BUG on data corruption (Kees Cook <keescook@...omium.org>)
Re: [PATCH 4/5] bug: Provide toggle for BUG on data corruption ("Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>)
Re: [PATCH 4/5] bug: Provide toggle for BUG on data corruption ("Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>)
Re: [PATCH v2 0/5] bug: Provide toggle for BUG on data corruption (Henrique de Moraes Holschuh <hmh@....eng.br>)
Re: [PATCH v2 1/5] list: Split list_add() debug checking into separate function (Steven Rostedt <rostedt@...dmis.org>)
Re: [PATCH v2 4/5] bug: Provide toggle for BUG on data corruption (Steven Rostedt <rostedt@...dmis.org>)
Re: [PATCH 4/5] bug: Provide toggle for BUG on data corruption ("Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>)
Re: [PATCH 4/5] bug: Provide toggle for BUG on data corruption (Kees Cook <keescook@...omium.org>)
Re: [PATCH 4/5] bug: Provide toggle for BUG on data corruption ("Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>)
[PATCH v1] kexec/arch/i386: Add support for KASLR memory randomization (Thomas Garnier <thgarnie@...gle.com>)
Re: [PATCH v2 0/5] bug: Provide toggle for BUG on data corruption (Stephen Boyd <sboyd@...eaurora.org>)
Re: [PATCH v2 0/5] bug: Provide toggle for BUG on data corruption (Kees Cook <keescook@...omium.org>)
[PATCH v3 1/5] list: Split list_add() debug checking into separate function (Kees Cook <keescook@...omium.org>)
[PATCH v3 2/5] rculist: Consolidate DEBUG_LIST for list_add_rcu() (Kees Cook <keescook@...omium.org>)
[PATCH v3 3/5] list: Split list_del() debug checking into separate function (Kees Cook <keescook@...omium.org>)
[PATCH v3 4/5] bug: Provide toggle for BUG on data corruption (Kees Cook <keescook@...omium.org>)
[PATCH v3 0/5] bug: Provide toggle for BUG on data corruption (Kees Cook <keescook@...omium.org>)
[PATCH v3 5/5] lkdtm: Add tests for struct list corruption (Kees Cook <keescook@...omium.org>)

August 18 (6 messages)

Re: [PATCH v1] kexec/arch/i386: Add support for KASLR memory randomization (Baoquan He <bhe@...hat.com>)
Re: [PATCH v3 0/5] bug: Provide toggle for BUG on data corruption (Steven Rostedt <rostedt@...dmis.org>)
[PATCH v1] kdump, vmcoreinfo: report memory sections virtual addresses (Thomas Garnier <thgarnie@...gle.com>)
Re: [PATCH v3 0/5] bug: Provide toggle for BUG on data corruption ("Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>)
Re: [PATCH v3 0/5] bug: Provide toggle for BUG on data corruption (Rik van Riel <riel@...hat.com>)
Re: [PATCH v3 0/5] bug: Provide toggle for BUG on data corruption ("Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>)

August 19 (4 messages)

Re: [PATCH v1] kdump, vmcoreinfo: report memory sections virtual addresses (Baoquan He <bhe@...hat.com>)
Re: [PATCH v3 0/5] bug: Provide toggle for BUG on data corruption (Rik van Riel <riel@...hat.com>)
Re: [PATCH v3 0/5] bug: Provide toggle for BUG on data corruption ("Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>)
Re: [PATCH v1] kdump, vmcoreinfo: report memory sections virtual addresses (Kees Cook <keescook@...omium.org>)

August 22 (3 messages)

Re: [PATCH v3 4/5] bug: Provide toggle for BUG on data corruption (Arnd Bergmann <arnd@...db.de>)
Re: [PATCH v3 4/5] bug: Provide toggle for BUG on data corruption ("Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>)
Re: Re: [PATCH v3 4/5] bug: Provide toggle for BUG on data corruption (Kees Cook <keescook@...omium.org>)

August 23 (1 message)

Re: [PATCH v1] kexec/arch/i386: Add support for KASLR memory randomization (Thomas Garnier <thgarnie@...gle.com>)

August 25 (18 messages)

[RFC v2 06/10] landlock: Add LSM hooks (Mickaël Salaün <mic@...ikod.net>)
[RFC v2 02/10] bpf: Move u64_to_ptr() to BPF headers and inline it (Mickaël Salaün <mic@...ikod.net>)
[RFC v2 00/10] Landlock LSM: Unprivileged sandboxing (Mickaël Salaün <mic@...ikod.net>)
[RFC v2 01/10] landlock: Add Kconfig (Mickaël Salaün <mic@...ikod.net>)
[RFC v2 04/10] seccomp: Split put_seccomp_filter() with put_seccomp() (Mickaël Salaün <mic@...ikod.net>)
[RFC v2 03/10] bpf,landlock: Add a new arraymap type to deal with (Landlock) handles (Mickaël Salaün <mic@...ikod.net>)
[RFC v2 05/10] seccomp: Handle Landlock (Mickaël Salaün <mic@...ikod.net>)
[RFC v2 09/10] landlock: Handle cgroups (Mickaël Salaün <mic@...ikod.net>)
[RFC v2 07/10] landlock: Add errno check (Mickaël Salaün <mic@...ikod.net>)
[RFC v2 08/10] landlock: Handle file system comparisons (Mickaël Salaün <mic@...ikod.net>)
[RFC v2 10/10] samples/landlock: Add sandbox example (Mickaël Salaün <mic@...ikod.net>)
Re: [RFC v2 00/10] Landlock LSM: Unprivileged sandboxing (Andy Lutomirski <luto@...capital.net>)
Re: [RFC v2 09/10] landlock: Handle cgroups (Andy Lutomirski <luto@...capital.net>)
Re: [RFC v2 08/10] landlock: Handle file system comparisons (Andy Lutomirski <luto@...capital.net>)
Re: [RFC v2 07/10] landlock: Add errno check (Andy Lutomirski <luto@...capital.net>)
Re: [RFC v2 00/10] Landlock LSM: Unprivileged sandboxing (Mickaël Salaün <mic@...ikod.net>)
Re: [RFC v2 08/10] landlock: Handle file system comparisons (Mickaël Salaün <mic@...ikod.net>)
Re: [RFC v2 09/10] landlock: Handle cgroups (Mickaël Salaün <mic@...ikod.net>)

August 26 (11 messages)

Re: [RFC v2 09/10] landlock: Handle cgroups (Alexei Starovoitov <alexei.starovoitov@...il.com>)
Re: [RFC v2 09/10] landlock: Handle cgroups (Tejun Heo <tj@...nel.org>)
Re: [RFC v2 09/10] landlock: Handle cgroups (Andy Lutomirski <luto@...capital.net>)
[PATCH] lib: harden strncpy_from_user (Mark Rutland <mark.rutland@....com>)
Re: [RFC v2 08/10] landlock: Handle file system comparisons (Andy Lutomirski <luto@...capital.net>)
Re: [RFC v2 09/10] landlock: Handle cgroups (Mickaël Salaün <mic@...ikod.net>)
Re: [PATCH 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching (David Brown <david.brown@...aro.org>)
Re: [RFC v2 09/10] landlock: Handle cgroups (Tejun Heo <tj@...nel.org>)
Re: [PATCH 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching (Catalin Marinas <catalin.marinas@....com>)
Re: [PATCH] lib: harden strncpy_from_user (Kees Cook <keescook@...omium.org>)
Re: [RFC v2 09/10] landlock: Handle cgroups (Alexei Starovoitov <alexei.starovoitov@...il.com>)

August 27 (18 messages)

Re: [RFC v2 09/10] landlock: Handle cgroups (Andy Lutomirski <luto@...capital.net>)
Re: [RFC v2 00/10] Landlock LSM: Unprivileged sandboxing (Andy Lutomirski <luto@...capital.net>)
Re: [RFC v2 08/10] landlock: Handle file system comparisons (Mickaël Salaün <mic@...ikod.net>)
Re: [RFC v2 09/10] landlock: Handle cgroups (performance) (Mickaël Salaün <mic@...ikod.net>)
Re: [RFC v2 09/10] landlock: Handle cgroups (netfilter match) (Mickaël Salaün <mic@...ikod.net>)
Re: [RFC v2 09/10] landlock: Handle cgroups (program types) (Mickaël Salaün <mic@...ikod.net>)
Re: [RFC v2 00/10] Landlock LSM: Unprivileged sandboxing (Mickaël Salaün <mic@...ikod.net>)
Re: [RFC v2 00/10] Landlock LSM: Unprivileged sandboxing (cgroup delegation) (Mickaël Salaün <mic@...ikod.net>)
Re: [RFC v2 09/10] landlock: Handle cgroups (performance) (Alexei Starovoitov <alexei.starovoitov@...il.com>)
Re: [RFC v2 09/10] landlock: Handle cgroups (Alexei Starovoitov <alexei.starovoitov@...il.com>)
Re: [RFC v2 09/10] landlock: Handle cgroups (program types) (Alexei Starovoitov <alexei.starovoitov@...il.com>)
Re: [RFC v2 09/10] landlock: Handle cgroups (netfilter match) (Alexei Starovoitov <alexei.starovoitov@...il.com>)
Re: [RFC v2 09/10] landlock: Handle cgroups (performance) (Mickaël Salaün <mic@...ikod.net>)
Re: [RFC v2 09/10] landlock: Handle cgroups (program types) (Mickaël Salaün <mic@...ikod.net>)
Re: [RFC v2 09/10] landlock: Handle cgroups (performance) (Alexei Starovoitov <alexei.starovoitov@...il.com>)
Re: [RFC v2 09/10] landlock: Handle cgroups (program types) (Alexei Starovoitov <alexei.starovoitov@...il.com>)
Re: [RFC v2 09/10] landlock: Handle cgroups (performance) (Mickaël Salaün <mic@...ikod.net>)
Re: [RFC v2 09/10] landlock: Handle cgroups (program types) (Mickaël Salaün <mic@...ikod.net>)

August 28 (3 messages)

Re: [RFC v2 09/10] landlock: Handle cgroups (performance) (Andy Lutomirski <luto@...capital.net>)
Re: [RFC v2 09/10] landlock: Handle cgroups (Andy Lutomirski <luto@...capital.net>)
Re: [RFC v2 09/10] landlock: Handle cgroups (performance) (Mickaël Salaün <mic@...ikod.net>)

August 29 (2 messages)

Re: [PATCH v1] kdump, vmcoreinfo: report memory sections virtual addresses (Baoquan He <bhe@...hat.com>)
Re: [PATCH v1] kdump, vmcoreinfo: report memory sections virtual addresses (Thomas Garnier <thgarnie@...gle.com>)

August 30 (16 messages)

Re: [RFC v2 00/10] Landlock LSM: Unprivileged sandboxing (Andy Lutomirski <luto@...capital.net>)
Re: constification and cocci / kernel build test robot ? (Kees Cook <keescook@...omium.org>)
Re: [RFC v2 09/10] landlock: Handle cgroups (performance) (Andy Lutomirski <luto@...capital.net>)
Re: [RFC v2 06/10] landlock: Add LSM hooks (Andy Lutomirski <luto@...capital.net>)
Re: constification and cocci / kernel build test robot ? (Julia Lawall <julia.lawall@...6.fr>)
Re: [RFC v2 00/10] Landlock LSM: Unprivileged sandboxing (Mickaël Salaün <mic@...ikod.net>)
Re: [RFC v2 00/10] Landlock LSM: Unprivileged sandboxing (Andy Lutomirski <luto@...capital.net>)
Re: [RFC v2 06/10] landlock: Add LSM hooks (Mickaël Salaün <mic@...ikod.net>)
Re: [RFC v2 06/10] landlock: Add LSM hooks (Andy Lutomirski <luto@...capital.net>)
Re: [RFC v2 09/10] landlock: Handle cgroups (performance) (Mickaël Salaün <mic@...ikod.net>)
Re: [RFC v2 09/10] landlock: Handle cgroups (performance) (Andy Lutomirski <luto@...capital.net>)
Re: [RFC v2 06/10] landlock: Add LSM hooks (Mickaël Salaün <mic@...ikod.net>)
Re: [RFC v2 09/10] landlock: Handle cgroups (performance) (Mickaël Salaün <mic@...ikod.net>)
Re: [RFC v2 09/10] landlock: Handle cgroups (performance) (Alexei Starovoitov <alexei.starovoitov@...il.com>)
Re: [RFC v2 09/10] landlock: Handle cgroups (performance) (Andy Lutomirski <luto@...capital.net>)
Re: constification and cocci / kernel build test robot ? (Kees Cook <keescook@...omium.org>)

August 31 (6 messages)

Re: [RFC v2 09/10] landlock: Handle cgroups (performance) (Alexei Starovoitov <alexei.starovoitov@...il.com>)
Re: [RFC v2 09/10] landlock: Handle cgroups (performance) (Andy Lutomirski <luto@...capital.net>)
Re: constification and cocci / kernel build test robot ? (Julia Lawall <julia.lawall@...6.fr>)
Re: constification and cocci / kernel build test robot ? (Mark Rutland <mark.rutland@....com>)
Re: constification and cocci / kernel build test robot ? (Kees Cook <keescook@...omium.org>)
Re: constification and cocci / kernel build test robot ? (Mark Rutland <mark.rutland@....com>)

350 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.