Re: [PATCH] x86/hyperv/vtl: Replace real_mode_header only under Hyper-V

On 08.09.23 17:02, Saurabh Singh Sengar wrote: > On Fri, Sep 08, 2023 at 12:26:10PM +0200, Mathias Krause wrote: >> Booting a CONFIG_HYPERV_VTL_MODE=y enabled kernel on bare metal or a >> non-Hyper-V hypervisor leads to serve memory corruption as > > FWIW, CONFIG_HYPERV_VTL

Re: [PATCH] vmlinux.lds.h: drop unused __vermagic

Hi Jessica, On Mon, 21 Jan 2019 at 12:39, Mathias Krause wrote: > > On Wed, 2 Jan 2019 at 21:29, Jessica Yu wrote: > > > > +++ Mathias Krause [30/12/18 13:40 +0100]: > > >The reference to '__vermagic' is a relict from v2.5 times. And even > > >there it had

Re: [PATCH] vmlinux.lds.h: drop unused __vermagic

On Wed, 2 Jan 2019 at 21:29, Jessica Yu wrote: > > +++ Mathias Krause [30/12/18 13:40 +0100]: > >The reference to '__vermagic' is a relict from v2.5 times. And even > >there it had a very short life time, from v2.5.59 (commit 1d411b80ee18 > >("Module Sanity

[PATCH] vmlinux.lds.h: drop unused __vermagic

kernels nor modules contain a '__vermagic' section any more, so get rid of it. Signed-off-by: Mathias Krause Cc: Rusty Russell Cc: Jessica Yu --- include/asm-generic/vmlinux.lds.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.

[PATCH] kallsyms: lower alignment on ARM

or 256 bytes for 64 bit builds. Fix this by switching to '.balign' instead which is consistent across all architectures. Signed-off-by: Mathias Krause Cc: Catalin Marinas Cc: Will Deacon --- scripts/kallsyms.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts

Re: [PATCH] net: ipv6: xfrm6_state: remove VLA usage

On 9 March 2018 at 13:21, Andreas Christoforou wrote: > The kernel would like to have all stack VLA usage removed[1]. > > Signed-off-by: Andreas Christoforou > --- > net/ipv6/xfrm6_state.c | 8 +++- > 1 file changed, 7 insertions(+), 1

Re: [PATCH] net: ipv6: xfrm6_state: remove VLA usage

On 9 March 2018 at 13:21, Andreas Christoforou wrote: > The kernel would like to have all stack VLA usage removed[1]. > > Signed-off-by: Andreas Christoforou > --- > net/ipv6/xfrm6_state.c | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/net/ipv6/xfrm6_state.c

[tip:x86/urgent] x86/alternatives: Fix alt_max_short macro to really be a max()

Commit-ID: 6b32c126d33d5cb379bca280ab8acedc1ca978ff Gitweb: https://git.kernel.org/tip/6b32c126d33d5cb379bca280ab8acedc1ca978ff Author: Mathias Krause <mini...@googlemail.com> AuthorDate: Thu, 5 Oct 2017 20:30:12 +0200 Committer: Thomas Gleixner <t...@linutronix.de> Commit

[tip:x86/urgent] x86/alternatives: Fix alt_max_short macro to really be a max()

Commit-ID: 6b32c126d33d5cb379bca280ab8acedc1ca978ff Gitweb: https://git.kernel.org/tip/6b32c126d33d5cb379bca280ab8acedc1ca978ff Author: Mathias Krause AuthorDate: Thu, 5 Oct 2017 20:30:12 +0200 Committer: Thomas Gleixner CommitDate: Mon, 9 Oct 2017 13:35:17 +0200 x86/alternatives: Fix

[PATCH v2] x86/alternatives: Fix alt_max_short macro to really be a max()

value of -1 for the < operator ... *sigh* Btw., the one in asm/alternative-asm.h is correct. And, apparently, all current users of ALTERNATIVE_2() pass same sized alternatives, avoiding to hit the bug. [1] http://graphics.stanford.edu/~seander/bithacks.html#IntegerMinOrMax Fixes: dbe4058a6a44 ("x

[PATCH v2] x86/alternatives: Fix alt_max_short macro to really be a max()

value of -1 for the < operator ... *sigh* Btw., the one in asm/alternative-asm.h is correct. And, apparently, all current users of ALTERNATIVE_2() pass same sized alternatives, avoiding to hit the bug. [1] http://graphics.stanford.edu/~seander/bithacks.html#IntegerMinOrMax Fixes: dbe4058a6a44 (&

Re: [PATCH] x86/alternatives: Fix alt_max_short macro to really be a max()

On 5 October 2017 at 14:52, Michael Matz <m...@suse.de> wrote: > On Thu, 5 Oct 2017, Borislav Petkov wrote: >> On Thu, Oct 05, 2017 at 02:35:33PM +0200, Mathias Krause wrote: >> > Note the "<"! ...comment is wrong, though the implementation works! >&g

Re: [PATCH] x86/alternatives: Fix alt_max_short macro to really be a max()

On 5 October 2017 at 14:52, Michael Matz wrote: > On Thu, 5 Oct 2017, Borislav Petkov wrote: >> On Thu, Oct 05, 2017 at 02:35:33PM +0200, Mathias Krause wrote: >> > Note the "<"! ...comment is wrong, though the implementation works! >> >> I know, I reali

Re: [PATCH] x86/alternatives: Fix alt_max_short macro to really be a max()

On 5 October 2017 at 09:58, Mathias Krause <mini...@googlemail.com> wrote: > On 5 October 2017 at 09:38, Borislav Petkov <b...@alien8.de> wrote: >> On Wed, Oct 04, 2017 at 08:08:12PM +0200, Mathias Krause wrote: >>> diff --git a/arch/x86/include/asm/alternative

Re: [PATCH] x86/alternatives: Fix alt_max_short macro to really be a max()

On 5 October 2017 at 09:58, Mathias Krause wrote: > On 5 October 2017 at 09:38, Borislav Petkov wrote: >> On Wed, Oct 04, 2017 at 08:08:12PM +0200, Mathias Krause wrote: >>> diff --git a/arch/x86/include/asm/alternative.h >>> b/arch/x86/include/asm/alternati

Re: [PATCH] x86/alternatives: Fix alt_max_short macro to really be a max()

On 5 October 2017 at 09:38, Borislav Petkov <b...@alien8.de> wrote: > On Wed, Oct 04, 2017 at 08:08:12PM +0200, Mathias Krause wrote: >> The alt_max_short() macro in asm/alternative.h does not work as >> intended, leading to nasty bugs. E.g. alt_max_short("

Re: [PATCH] x86/alternatives: Fix alt_max_short macro to really be a max()

On 5 October 2017 at 09:38, Borislav Petkov wrote: > On Wed, Oct 04, 2017 at 08:08:12PM +0200, Mathias Krause wrote: >> The alt_max_short() macro in asm/alternative.h does not work as >> intended, leading to nasty bugs. E.g. alt_max_short("1", "3") >>

[PATCH] x86/alternatives: Fix alt_max_short macro to really be a max()

value of -1 for the < operator ... *sigh* Btw., the one in asm/alternative-asm.h is correct. And, apparently, all current users of ALTERNATIVE_2() pass same sized alternatives, avoiding to hit the bug. [1] http://graphics.stanford.edu/~seander/bithacks.html#IntegerMinOrMax Fixes: dbe4058a6a44 ("x

[PATCH] x86/alternatives: Fix alt_max_short macro to really be a max()

value of -1 for the < operator ... *sigh* Btw., the one in asm/alternative-asm.h is correct. And, apparently, all current users of ALTERNATIVE_2() pass same sized alternatives, avoiding to hit the bug. [1] http://graphics.stanford.edu/~seander/bithacks.html#IntegerMinOrMax Fixes: dbe4058a6a44 ("

[tip:x86/urgent] x86/vdso: Ensure vdso32_enabled gets set to valid values only

Commit-ID: c06989da39cdb10604d572c8c7ea8c8c97f3c483 Gitweb: http://git.kernel.org/tip/c06989da39cdb10604d572c8c7ea8c8c97f3c483 Author: Mathias Krause <mini...@googlemail.com> AuthorDate: Mon, 10 Apr 2017 17:14:27 +0200 Committer: Thomas Gleixner <t...@linutronix.de> CommitD

[tip:x86/urgent] x86/vdso: Ensure vdso32_enabled gets set to valid values only

Commit-ID: c06989da39cdb10604d572c8c7ea8c8c97f3c483 Gitweb: http://git.kernel.org/tip/c06989da39cdb10604d572c8c7ea8c8c97f3c483 Author: Mathias Krause AuthorDate: Mon, 10 Apr 2017 17:14:27 +0200 Committer: Thomas Gleixner CommitDate: Mon, 10 Apr 2017 18:31:41 +0200 x86/vdso: Ensure

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On 7 April 2017 at 15:14, Thomas Gleixner <t...@linutronix.de> wrote: > On Fri, 7 Apr 2017, Mathias Krause wrote: >> On 7 April 2017 at 11:46, Thomas Gleixner <t...@linutronix.de> wrote: >> > Whether protected by preempt_disable or local_irq_disable, to make that &

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On 7 April 2017 at 15:14, Thomas Gleixner wrote: > On Fri, 7 Apr 2017, Mathias Krause wrote: >> On 7 April 2017 at 11:46, Thomas Gleixner wrote: >> > Whether protected by preempt_disable or local_irq_disable, to make that >> > work it needs CR0 handling in the excepti

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On 7 April 2017 at 11:46, Thomas Gleixner <t...@linutronix.de> wrote: > On Fri, 7 Apr 2017, Mathias Krause wrote: >> On 6 April 2017 at 17:59, Andy Lutomirski <l...@amacapital.net> wrote: >> > On Wed, Apr 5, 2017 at 5:14 PM, Kees Cook <keesc...@chromium.org>

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On 7 April 2017 at 11:46, Thomas Gleixner wrote: > On Fri, 7 Apr 2017, Mathias Krause wrote: >> On 6 April 2017 at 17:59, Andy Lutomirski wrote: >> > On Wed, Apr 5, 2017 at 5:14 PM, Kees Cook wrote: >> >> static __always_inline rare_write_begin(void) >

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On 6 April 2017 at 17:59, Andy Lutomirski wrote: > On Wed, Apr 5, 2017 at 5:14 PM, Kees Cook wrote: >> On Wed, Apr 5, 2017 at 4:57 PM, Andy Lutomirski wrote: >>> On Wed, Mar 29, 2017 at 6:41 PM, Kees Cook

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On 6 April 2017 at 17:59, Andy Lutomirski wrote: > On Wed, Apr 5, 2017 at 5:14 PM, Kees Cook wrote: >> On Wed, Apr 5, 2017 at 4:57 PM, Andy Lutomirski wrote: >>> On Wed, Mar 29, 2017 at 6:41 PM, Kees Cook wrote: On Wed, Mar 29, 2017 at 3:38 PM, Andy Lutomirski wrote: > On Wed,

[PATCH] x86/vdso: ensure vdso32_enabled gets set to valid values only

pital.net> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Ingo Molnar <mi...@redhat.com> Cc: "H. Peter Anvin" <h...@zytor.com> Cc: Roland McGrath <rol...@redhat.com> Signed-off-by: Mathias Krause <mini...@googlemail.com> --- arch/x86/entry/vdso/vdso32-setup.

[PATCH] x86/vdso: ensure vdso32_enabled gets set to valid values only

Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Roland McGrath Signed-off-by: Mathias Krause --- arch/x86/entry/vdso/vdso32-setup.c | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/arch/x86/entry/vdso/vdso32-setup.c b/arch/x86/entry/vdso/vdso32-setup.

[PATCH v2] cris: remove unused wp_works_ok macro

It had no use since it's introduction in v2.4.1.2. Get rid of it. Cc: Mikael Starvik <star...@axis.com> Signed-off-by: Mathias Krause <mini...@googlemail.com> Acked-by: Jesper Nilsson <jesper.nils...@axis.com> --- Same patch as v1 but as the tip folks took only the x86 parts,

[PATCH v2] cris: remove unused wp_works_ok macro

It had no use since it's introduction in v2.4.1.2. Get rid of it. Cc: Mikael Starvik Signed-off-by: Mathias Krause Acked-by: Jesper Nilsson --- Same patch as v1 but as the tip folks took only the x86 parts, I think, this one should go through the CRIS tree. Cheers, Mathias arch/cris/include

[PATCH v2] sparc: remove unused wp_works_ok macro

It's unused for ages, used to be required for ksyms.c back in the v1.1 times. Signed-off-by: Mathias Krause <mini...@googlemail.com> Acked-by: David S. Miller <da...@davemloft.net> --- Hi Dave, same patch as v1 but as the tip folks took only the x86 parts, I think, this one shoul

[PATCH v2] sparc: remove unused wp_works_ok macro

It's unused for ages, used to be required for ksyms.c back in the v1.1 times. Signed-off-by: Mathias Krause Acked-by: David S. Miller --- Hi Dave, same patch as v1 but as the tip folks took only the x86 parts, I think, this one should go through the SPARC tree. Cheers, Mathias arch/sparc

[tip:x86/cpu] x86/cpu: Drop wp_works_ok member of struct cpuinfo_x86

Commit-ID: 6415813bae75feba10b8ca3ed6634a72c2a4d313 Gitweb: http://git.kernel.org/tip/6415813bae75feba10b8ca3ed6634a72c2a4d313 Author: Mathias Krause <mini...@googlemail.com> AuthorDate: Sun, 12 Feb 2017 22:12:08 +0100 Committer: Thomas Gleixner <t...@linutronix.de> CommitD

[tip:x86/cpu] x86/cpu: Drop wp_works_ok member of struct cpuinfo_x86

Commit-ID: 6415813bae75feba10b8ca3ed6634a72c2a4d313 Gitweb: http://git.kernel.org/tip/6415813bae75feba10b8ca3ed6634a72c2a4d313 Author: Mathias Krause AuthorDate: Sun, 12 Feb 2017 22:12:08 +0100 Committer: Thomas Gleixner CommitDate: Sat, 11 Mar 2017 14:30:24 +0100 x86/cpu: Drop

[tip:x86/cpu] x86/cpu: Drop unneded members of struct cpuinfo_x86

Commit-ID: 04402116846f36adea9503d7cd5104a7ed27a1a6 Gitweb: http://git.kernel.org/tip/04402116846f36adea9503d7cd5104a7ed27a1a6 Author: Mathias Krause <mini...@googlemail.com> AuthorDate: Sun, 12 Feb 2017 22:12:07 +0100 Committer: Thomas Gleixner <t...@linutronix.de> CommitD

[tip:x86/cpu] x86/cpu: Drop unneded members of struct cpuinfo_x86

Commit-ID: 04402116846f36adea9503d7cd5104a7ed27a1a6 Gitweb: http://git.kernel.org/tip/04402116846f36adea9503d7cd5104a7ed27a1a6 Author: Mathias Krause AuthorDate: Sun, 12 Feb 2017 22:12:07 +0100 Committer: Thomas Gleixner CommitDate: Sat, 11 Mar 2017 14:30:23 +0100 x86/cpu: Drop

Re: [PATCH 3/6] x86/cpu: proc - remove "wp" status line in cpuinfo

On 14 February 2017 at 22:42, Mathias Krause <mini...@googlemail.com> wrote: > On 14 February 2017 at 19:13, H. Peter Anvin <h...@zytor.com> wrote: >> On 02/12/17 13:12, Mathias Krause wrote: >>> As of commit a5c2a893dbd4 ("x86, 386 removal: Remove >>&g

Re: [PATCH 3/6] x86/cpu: proc - remove "wp" status line in cpuinfo

On 14 February 2017 at 22:42, Mathias Krause wrote: > On 14 February 2017 at 19:13, H. Peter Anvin wrote: >> On 02/12/17 13:12, Mathias Krause wrote: >>> As of commit a5c2a893dbd4 ("x86, 386 removal: Remove >>> CONFIG_X86_WP_WORKS_OK") the kernel won't boot

Re: [PATCH 3/6] x86/cpu: proc - remove "wp" status line in cpuinfo

On 14 February 2017 at 19:13, H. Peter Anvin <h...@zytor.com> wrote: > On 02/12/17 13:12, Mathias Krause wrote: >> As of commit a5c2a893dbd4 ("x86, 386 removal: Remove >> CONFIG_X86_WP_WORKS_OK") the kernel won't boot if CR0.WP isn't working >> correctly. T

Re: [PATCH 3/6] x86/cpu: proc - remove "wp" status line in cpuinfo

On 14 February 2017 at 19:13, H. Peter Anvin wrote: > On 02/12/17 13:12, Mathias Krause wrote: >> As of commit a5c2a893dbd4 ("x86, 386 removal: Remove >> CONFIG_X86_WP_WORKS_OK") the kernel won't boot if CR0.WP isn't working >> correctly. This makes a process r

Re: [PATCH 3/6] x86/cpu: proc - remove "wp" status line in cpuinfo

On 14 February 2017 at 17:20, Borislav Petkov <b...@alien8.de> wrote: > On Sun, Feb 12, 2017 at 10:12:09PM +0100, Mathias Krause wrote: >> As of commit a5c2a893dbd4 ("x86, 386 removal: Remove >> CONFIG_X86_WP_WORKS_OK") the kernel won't boot if CR0.WP isn't w

Re: [PATCH 3/6] x86/cpu: proc - remove "wp" status line in cpuinfo

On 14 February 2017 at 17:20, Borislav Petkov wrote: > On Sun, Feb 12, 2017 at 10:12:09PM +0100, Mathias Krause wrote: >> As of commit a5c2a893dbd4 ("x86, 386 removal: Remove >> CONFIG_X86_WP_WORKS_OK") the kernel won't boot if CR0.WP isn't working >> correctl

Re: [PATCH 1/6] x86: drop unneded members of struct cpuinfo_x86

On 14 February 2017 at 17:17, Borislav Petkov <b...@alien8.de> wrote: > On Sun, Feb 12, 2017 at 10:12:07PM +0100, Mathias Krause wrote: >> Those member serve no purpose -- not even fill padding for alignment or >> such. So just get rid of them. > > Well, almost. You n

Re: [PATCH 1/6] x86: drop unneded members of struct cpuinfo_x86

On 14 February 2017 at 17:17, Borislav Petkov wrote: > On Sun, Feb 12, 2017 at 10:12:07PM +0100, Mathias Krause wrote: >> Those member serve no purpose -- not even fill padding for alignment or >> such. So just get rid of them. > > Well, almost. You need the wp_works

[PATCH 2/6] x86/cpu: drop wp_works_ok member of struct cpuinfo_x86

r Anvin <h...@linux.intel.com> Cc: Arnd Hannemann <hannem...@nets.rwth-aachen.de> Cc: Jeremy Fitzhardinge <jeremy.fitzhardi...@citrix.com> Signed-off-by: Mathias Krause <mini...@googlemail.com> --- arch/x86/include/asm/processor.h |4 +--- arch/x86/kernel/cpu/pro

[PATCH 4/6] sparc: remove unused wp_works_ok macro

It's unused for ages, used to be required for ksyms.c back in the v1.1 times. Cc: David S. Miller <da...@davemloft.net> Signed-off-by: Mathias Krause <mini...@googlemail.com> --- arch/sparc/include/asm/processor_32.h |6 -- arch/sparc/include/asm/processor_64.h |4 -

[PATCH 2/6] x86/cpu: drop wp_works_ok member of struct cpuinfo_x86

annemann Cc: Jeremy Fitzhardinge Signed-off-by: Mathias Krause --- arch/x86/include/asm/processor.h |4 +--- arch/x86/kernel/cpu/proc.c |5 ++--- arch/x86/kernel/setup.c | 11 --- arch/x86/mm/init_32.c|9 + arch/x86/xen/enlighten.c

[PATCH 4/6] sparc: remove unused wp_works_ok macro

It's unused for ages, used to be required for ksyms.c back in the v1.1 times. Cc: David S. Miller Signed-off-by: Mathias Krause --- arch/sparc/include/asm/processor_32.h |6 -- arch/sparc/include/asm/processor_64.h |4 2 files changed, 10 deletions(-) diff --git a/arch/sparc

[PATCH 3/6] x86/cpu: proc - remove "wp" status line in cpuinfo

ine in /proc/cpuinfo serves no purpose for quite some time now, get rid of it. Cc: Borislav Petkov <b...@alien8.de> Cc: H. Peter Anvin <h...@linux.intel.com> Signed-off-by: Mathias Krause <mini...@googlemail.com> --- arch/x86/kernel/cpu/proc.c |6 ++ 1 file changed, 2 ins

[PATCH 6/6] m68k: paging_init - remove dead code

The macro TEST_VERIFY_AREA can never be defined as there's no wp_works_ok variable. So just remove the dead code. Cc: Geert Uytterhoeven <ge...@linux-m68k.org> Signed-off-by: Mathias Krause <mini...@googlemail.com> --- arch/m68k/mm/sun3mmu.c |3 --- 1 file changed, 3 deletions(-)

[PATCH 3/6] x86/cpu: proc - remove "wp" status line in cpuinfo

ine in /proc/cpuinfo serves no purpose for quite some time now, get rid of it. Cc: Borislav Petkov Cc: H. Peter Anvin Signed-off-by: Mathias Krause --- arch/x86/kernel/cpu/proc.c |6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/x86/kernel/cpu/proc.c b/arch/x86/ker

[PATCH 6/6] m68k: paging_init - remove dead code

The macro TEST_VERIFY_AREA can never be defined as there's no wp_works_ok variable. So just remove the dead code. Cc: Geert Uytterhoeven Signed-off-by: Mathias Krause --- arch/m68k/mm/sun3mmu.c |3 --- 1 file changed, 3 deletions(-) diff --git a/arch/m68k/mm/sun3mmu.c b/arch/m68k/mm

[PATCH 5/6] cris: remove unused wp_works_ok macro

It had no use since it's introduction in v2.4.1.2. Get rid of it. Cc: Jesper Nilsson <jesper.nils...@axis.com> Cc: Mikael Starvik <star...@axis.com> Signed-off-by: Mathias Krause <mini...@googlemail.com> --- arch/cris/include/arch-v10/arch/processor.h |3 --- 1 file ch

[PATCH 5/6] cris: remove unused wp_works_ok macro

It had no use since it's introduction in v2.4.1.2. Get rid of it. Cc: Jesper Nilsson Cc: Mikael Starvik Signed-off-by: Mathias Krause --- arch/cris/include/arch-v10/arch/processor.h |3 --- 1 file changed, 3 deletions(-) diff --git a/arch/cris/include/arch-v10/arch/processor.h b/arch

[PATCH 0/6] struct cpuinfo_x86 related cleanups

are long gone, so we can get rid of that ancient hackery. Therefore patches 4, 5 and 6 are independent of the x86 specific changes and could be taken by the individual arch maintainers if they prefer to. Please apply, Mathias Mathias Krause (6): x86: drop unneded members of struct cpuinfo_x86 x86

[PATCH 1/6] x86: drop unneded members of struct cpuinfo_x86

Those member serve no purpose -- not even fill padding for alignment or such. So just get rid of them. Cc: Borislav Petkov <b...@alien8.de> Cc: H. Peter Anvin <h...@linux.intel.com> Signed-off-by: Mathias Krause <mini...@googlemail.com> --- arch/x86/include/asm/processor.h |

[PATCH 0/6] struct cpuinfo_x86 related cleanups

are long gone, so we can get rid of that ancient hackery. Therefore patches 4, 5 and 6 are independent of the x86 specific changes and could be taken by the individual arch maintainers if they prefer to. Please apply, Mathias Mathias Krause (6): x86: drop unneded members of struct cpuinfo_x86 x86

[PATCH 1/6] x86: drop unneded members of struct cpuinfo_x86

Those member serve no purpose -- not even fill padding for alignment or such. So just get rid of them. Cc: Borislav Petkov Cc: H. Peter Anvin Signed-off-by: Mathias Krause --- arch/x86/include/asm/processor.h |7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/arch

Re: [PATCH v1 0/2] Introduce the initify gcc plugin

Hi Emese, On Tue, Jun 28, 2016 at 01:34:07PM +0200, Emese Revfy wrote: > I would like to introduce the initify gcc plugin. The kernel already has > a mechanism to free up code and data memory that is only used during kernel > or module initialization. > This plugin will teach the compiler to find

Re: [PATCH v1 0/2] Introduce the initify gcc plugin

Hi Emese, On Tue, Jun 28, 2016 at 01:34:07PM +0200, Emese Revfy wrote: > I would like to introduce the initify gcc plugin. The kernel already has > a mechanism to free up code and data memory that is only used during kernel > or module initialization. > This plugin will teach the compiler to find

[tip:x86/mm] x86/extable: Ensure entries are swapped completely when sorting

Commit-ID: 67d7a982bab6702d84415ea889996fae72a7d3b2 Gitweb: http://git.kernel.org/tip/67d7a982bab6702d84415ea889996fae72a7d3b2 Author: Mathias Krause <mini...@googlemail.com> AuthorDate: Tue, 10 May 2016 23:07:02 +0200 Committer: Ingo Molnar <mi...@kernel.org> CommitDate:

[tip:x86/mm] x86/extable: Ensure entries are swapped completely when sorting

Commit-ID: 67d7a982bab6702d84415ea889996fae72a7d3b2 Gitweb: http://git.kernel.org/tip/67d7a982bab6702d84415ea889996fae72a7d3b2 Author: Mathias Krause AuthorDate: Tue, 10 May 2016 23:07:02 +0200 Committer: Ingo Molnar CommitDate: Wed, 11 May 2016 11:14:06 +0200 x86/extable: Ensure

Re: [PATCH] x86/extable: ensure entries are swapped completely when sorting

On 11 May 2016 at 07:46, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > On 10 May 2016 at 23:07, Mathias Krause <mini...@googlemail.com> wrote: >> The x86 exception table sorting was changed in commit 29934b0fb8ff >> ("x86/extable: use generic search and

Re: [PATCH] x86/extable: ensure entries are swapped completely when sorting

On 11 May 2016 at 07:46, Ard Biesheuvel wrote: > On 10 May 2016 at 23:07, Mathias Krause wrote: >> The x86 exception table sorting was changed in commit 29934b0fb8ff >> ("x86/extable: use generic search and sort routines") to use the arch >> independent code in li

[PATCH] x86/extable: ensure entries are swapped completely when sorting

_entry_fixup() macro that takes care of the 'handler' member. [1] https://lkml.org/lkml/2016/1/27/232 Signed-off-by: Mathias Krause <mini...@googlemail.com> Cc: Andrew Morton <a...@linux-foundation.org> Cc: Andy Lutomirski <l...@kernel.org> Cc: Ard Biesheuvel <ard.bies

[PATCH] x86/extable: ensure entries are swapped completely when sorting

_entry_fixup() macro that takes care of the 'handler' member. [1] https://lkml.org/lkml/2016/1/27/232 Signed-off-by: Mathias Krause Cc: Andrew Morton Cc: Andy Lutomirski Cc: Ard Biesheuvel Cc: Borislav Petkov Cc: H. Peter Anvin Cc: Ingo Molnar Cc: Linus Torvalds Cc: Thomas Gleixner Cc:

Re: [PATCH] proc: prevent accessing /proc//environ until it's ready

On 28 April 2016 at 23:30, Andrew Morton <a...@linux-foundation.org> wrote: > On Thu, 28 Apr 2016 21:04:18 +0200 Mathias Krause <mini...@googlemail.com> > wrote: > >> If /proc//environ gets read before the envp[] array is fully set >> up in create_{aout,elf,elf_f

Re: [PATCH] proc: prevent accessing /proc//environ until it's ready

On 28 April 2016 at 23:30, Andrew Morton wrote: > On Thu, 28 Apr 2016 21:04:18 +0200 Mathias Krause > wrote: > >> If /proc//environ gets read before the envp[] array is fully set >> up in create_{aout,elf,elf_fdpic,flat}_tables(), we might end up trying >> to read m

Re: [PATCH] proc: prevent accessing /proc//environ until it's ready

On 28 April 2016 at 23:26, Andrew Morton <a...@linux-foundation.org> wrote: > On Thu, 28 Apr 2016 21:04:18 +0200 Mathias Krause <mini...@googlemail.com> > wrote: > >> If /proc//environ gets read before the envp[] array is fully set >> up in create_{aout,elf,elf_f

Re: [PATCH] proc: prevent accessing /proc//environ until it's ready

On 28 April 2016 at 23:26, Andrew Morton wrote: > On Thu, 28 Apr 2016 21:04:18 +0200 Mathias Krause > wrote: > >> If /proc//environ gets read before the envp[] array is fully set >> up in create_{aout,elf,elf_fdpic,flat}_tables(), we might end up trying >> to read m

Re: [PATCH] proc: prevent accessing /proc//environ until it's ready

On 28 April 2016 at 21:20, Mateusz Guzik wrote: > In this case get_cmdline in mm/util.c should also be patched for > completness. It tests for arg_end, but later accesses env_end. But it'll do this only when argv[] was modified from what the kernel initially wrote, which, in

Re: [PATCH] proc: prevent accessing /proc//environ until it's ready

On 28 April 2016 at 21:20, Mateusz Guzik wrote: > In this case get_cmdline in mm/util.c should also be patched for > completness. It tests for arg_end, but later accesses env_end. But it'll do this only when argv[] was modified from what the kernel initially wrote, which, in turn, either

[PATCH] proc: prevent accessing /proc//environ until it's ready

- (env_start + src)' when env_end is still zero. Reported-at: https://forums.grsecurity.net/viewtopic.php?f=3=4363 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116461 Signed-off-by: Mathias Krause <mini...@googlemail.com> Cc: Emese Revfy <re.em...@gmail.com> Cc: Pax

[PATCH] proc: prevent accessing /proc//environ until it's ready

- (env_start + src)' when env_end is still zero. Reported-at: https://forums.grsecurity.net/viewtopic.php?f=3=4363 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116461 Signed-off-by: Mathias Krause Cc: Emese Revfy Cc: Pax Team Cc: Al Viro Cc: Mateusz Guzik Cc: Alexey Dobriyan Cc: Cyrill

Re: [kernel-hardening] [RFC][PATCH 0/3] Sanitization of buddy pages

s no longer available. Discussion of > sanitization was brough up in a thread about CVEs > (lkml.kernel.org/g/<20160119112812.GA10818@mwanda>) > > I eventually expect Kconfig names will want to be changed and or moved if this > is going to be used for security but that can happen later. >

Re: [kernel-hardening] [RFC][PATCH 0/3] Sanitization of buddy pages

y sensitive data is no longer available. Discussion of > sanitization was brough up in a thread about CVEs > (lkml.kernel.org/g/<20160119112812.GA10818@mwanda>) > > I eventually expect Kconfig names will want to be changed and or moved if this > is going to be used for secu

Re: [PATCH] ACPI / OSL: Add kerneldoc comments to memory mapping functions

On 2 January 2016 at 03:10, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Add kerneldoc comments to acpi_os_map_iomem() and acpi_os_unmap_iomem() > and explain why the latter needs the __ref annotation in one of them > (as suggested by Mathias Krause). > > Si

Re: [PATCH] ACPI / OSL: Add kerneldoc comments to memory mapping functions

of them > (as suggested by Mathias Krause). > > Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com> > --- > drivers/acpi/osl.c | 27 +++ > 1 file changed, 27 insertions(+) > > Index: linux-pm/drivers/acpi/osl.c > ==

Re: [kernel-hardening] [RFC][PATCH 6/7] mm: Add Kconfig option for slab sanitization

On 22 December 2015 at 21:01, Christoph Lameter wrote: > On Tue, 22 Dec 2015, Mathias Krause wrote: > >> How many systems, do you think, are running with enabled DEBUG_SLAB / >> SLUB_DEBUG in production? Not so many, I'd guess. And the ones running >> into issues probably

Re: [kernel-hardening] [RFC][PATCH 6/7] mm: Add Kconfig option for slab sanitization

On 22 December 2015 at 18:51, Laura Abbott wrote: >> [snip] >> >> Related to this, have you checked that the sanitization doesn't >> interfere with the various slab handling schemes, namely RCU related >> specialties? Not all caches are marked SLAB_DESTROY_BY_RCU, some use >> call_rcu() instead,

Re: [kernel-hardening] [RFC][PATCH 6/7] mm: Add Kconfig option for slab sanitization

On 22 December 2015 at 04:40, Laura Abbott wrote: > > The SL[AOU]B allocators all behave differently w.r.t. to what happen > an object is freed. CONFIG_SLAB_SANITIZATION introduces a common > mechanism to control what happens on free. When this option is > enabled, objects may be poisoned

Re: [kernel-hardening] [RFC][PATCH 6/7] mm: Add Kconfig option for slab sanitization

On 22 December 2015 at 21:01, Christoph Lameter <c...@linux.com> wrote: > On Tue, 22 Dec 2015, Mathias Krause wrote: > >> How many systems, do you think, are running with enabled DEBUG_SLAB / >> SLUB_DEBUG in production? Not so many, I'd guess. And the ones running >

Re: [kernel-hardening] [RFC][PATCH 6/7] mm: Add Kconfig option for slab sanitization

On 22 December 2015 at 04:40, Laura Abbott wrote: > > The SL[AOU]B allocators all behave differently w.r.t. to what happen > an object is freed. CONFIG_SLAB_SANITIZATION introduces a common > mechanism to control what happens on free. When this option is > enabled, objects may

Re: [kernel-hardening] [RFC][PATCH 6/7] mm: Add Kconfig option for slab sanitization

On 22 December 2015 at 18:51, Laura Abbott wrote: >> [snip] >> >> Related to this, have you checked that the sanitization doesn't >> interfere with the various slab handling schemes, namely RCU related >> specialties? Not all caches are marked SLAB_DESTROY_BY_RCU, some use >>

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On 29 November 2015 at 16:39, Ingo Molnar wrote: > > * PaX Team wrote: > >> On 29 Nov 2015 at 9:08, Ingo Molnar wrote: >> >> > >> > * PaX Team wrote: >> > >> > > i don't see the compile time vs. runtime detection as 'competing' >> > > approaches, >> > > both have their own role. [...] >> > >>

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On 29 November 2015 at 16:39, Ingo Molnar wrote: > > * PaX Team wrote: > >> On 29 Nov 2015 at 9:08, Ingo Molnar wrote: >> >> > >> > * PaX Team wrote: >> > >> > > i don't see the compile time vs. runtime detection as 'competing' >> >

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On 24 November 2015 at 22:38, Kees Cook wrote: > Many things are written to only during __init, and never changed > again. These cannot be made "const" since the compiler will do the wrong > thing (we do actually need to write to them). Instead, move these items > into a memory region that will

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On 24 November 2015 at 22:38, Kees Cook wrote: > Many things are written to only during __init, and never changed > again. These cannot be made "const" since the compiler will do the wrong > thing (we do actually need to write to them). Instead, move these items > into a

[PATCH] printk: prevent userland from spoofing kernel messages

Fixes: 7ff9554bb578 ("printk: convert byte-buffer to variable-length...") Signed-off-by: Mathias Krause Cc: Greg Kroah-Hartman Cc: Petr Mladek Cc: Alex Elder Cc: Joe Perches Cc: Kay Sievers --- Might be worth to apply to stable, too. Don't know. Prior to commit 7ff9554bb578 there w

[PATCH] printk: prevent userland from spoofing kernel messages

Fixes: 7ff9554bb578 ("printk: convert byte-buffer to variable-length...") Signed-off-by: Mathias Krause <mini...@googlemail.com> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> Cc: Petr Mladek <pmla...@suse.cz> Cc: Alex Elder <el...@linaro.org> Cc: Joe Perches <j

Re: [PATCH v2 1/3] unix: fix use-after-free in unix_dgram_poll()

ram_disconnected(sk, other); > @@ -2441,7 +2472,6 @@ static unsigned int unix_dgram_poll(struct file *file, > struct socket *sock, > other = unix_peer_get(sk); > if (other) { > if (unix_peer(other) != sk) { > - sock_poll_wait(file, _sk(other)->peer_wait, > wait); > if (unix_recvq_full(other)) > writable = 0; > } > -- > 1.8.2.rc2 > My reproducer runs on this patch for more than 3 days now without triggering anything anymore. Tested-by: Mathias Krause Thanks Jason! Regards, Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH v2 1/3] unix: fix use-after-free in unix_dgram_poll()

ck(sk); > > unix_dgram_disconnected(sk, other); > @@ -2441,7 +2472,6 @@ static unsigned int unix_dgram_poll(struct file *file, > struct socket *sock, > other = unix_peer_get(sk); > if (other) { > if (unix_peer(other) != sk

Re: [PATCH v13 13/23] x86/asm/crypto: Create stack frames in aesni-intel_asm.S

On Do, Okt 01, 2015 at 08:29:50 -0500, Josh Poimboeuf wrote: > On Thu, Oct 01, 2015 at 08:10:26AM +0200, mini...@ld-linux.so wrote: > > On Tue, Sep 22, 2015 at 10:47:04AM -0500, Josh Poimboeuf wrote: > > > ENTRY(aesni_set_key) > > > + FRAME_BEGIN > > > #ifndef __x86_64__ > > > pushl KEYP > > >

Re: [PATCH v13 13/23] x86/asm/crypto: Create stack frames in aesni-intel_asm.S

On Do, Okt 01, 2015 at 08:29:50 -0500, Josh Poimboeuf wrote: > On Thu, Oct 01, 2015 at 08:10:26AM +0200, mini...@ld-linux.so wrote: > > On Tue, Sep 22, 2015 at 10:47:04AM -0500, Josh Poimboeuf wrote: > > > ENTRY(aesni_set_key) > > > + FRAME_BEGIN > > > #ifndef __x86_64__ > > > pushl KEYP > > >

Re: List corruption on epoll_ctl(EPOLL_CTL_DEL) an AF_UNIX socket

On 30 September 2015 at 15:25, Rainer Weikusat wrote: > Mathias Krause writes: >> On 30 September 2015 at 12:56, Rainer Weikusat >> wrote: >>> In case you want some information on this: This is a kernel warning I >>> could trigger (more than once) on th

Re: List corruption on epoll_ctl(EPOLL_CTL_DEL) an AF_UNIX socket

On 30 September 2015 at 12:56, Rainer Weikusat wrote: > Mathias Krause writes: >> On 29 September 2015 at 21:09, Jason Baron wrote: >>> However, if we call connect on socket 's', to connect to a new socket 'o2', >>> we >>> drop the reference on the origina

Re: List corruption on epoll_ctl(EPOLL_CTL_DEL) an AF_UNIX socket

On 30 September 2015 at 12:56, Rainer Weikusat <rweiku...@mobileactivedefense.com> wrote: > Mathias Krause <mini...@googlemail.com> writes: >> On 29 September 2015 at 21:09, Jason Baron <jba...@akamai.com> wrote: >>> However, if we call connect on socket

Re: List corruption on epoll_ctl(EPOLL_CTL_DEL) an AF_UNIX socket

On 30 September 2015 at 15:25, Rainer Weikusat <rweiku...@mobileactivedefense.com> wrote: > Mathias Krause <mini...@googlemail.com> writes: >> On 30 September 2015 at 12:56, Rainer Weikusat >> <rweiku...@mobileactivedefense.com> wrote: >

Re: List corruption on epoll_ctl(EPOLL_CTL_DEL) an AF_UNIX socket

On 29 September 2015 at 21:09, Jason Baron wrote: > However, if we call connect on socket 's', to connect to a new socket 'o2', we > drop the reference on the original socket 'o'. Thus, we can now close socket > 'o' without unregistering from epoll. Then, when we either close the ep > or

  1   2   3   4   5   6   >