Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1720319 > unrolled thread

Re: [PATCH v8 02/28] x86/boot: Relocate definition of the initial state of CR0

Started byBorislav Petkov <bp@suse.de>
First post2017-08-25 19:50 +0200
Last post2017-09-02 19:40 +0200
Articles 4 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH v8 02/28] x86/boot: Relocate definition of the initial  state of CR0 Borislav Petkov <bp@suse.de> - 2017-08-25 19:50 +0200
    Re: [PATCH v8 02/28] x86/boot: Relocate definition of the initial  state of CR0 Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-08-31 06:10 +0200
      Re: [PATCH v8 02/28] x86/boot: Relocate definition of the initial  state of CR0 Borislav Petkov <bp@suse.de> - 2017-08-31 12:00 +0200
        Re: [PATCH v8 02/28] x86/boot: Relocate definition of the initial  state of CR0 Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-09-02 19:40 +0200

#1720319 — Re: [PATCH v8 02/28] x86/boot: Relocate definition of the initial state of CR0

FromBorislav Petkov <bp@suse.de>
Date2017-08-25 19:50 +0200
SubjectRe: [PATCH v8 02/28] x86/boot: Relocate definition of the initial state of CR0
Message-ID<uiqU3-71g-31@gated-at.bofh.it>
On Fri, Aug 18, 2017 at 05:27:43PM -0700, Ricardo Neri wrote:
> Both head_32.S and head_64.S utilize the same value to initialize the
> control register CR0. Also, other parts of the kernel might want to access
> to this initial definition (e.g., emulation code for User-Mode Instruction

s/to //

> Prevention uses this state to provide a sane dummy value for CR0 when
> emulating the smsw instruction). Thus, relocate this definition to a
> header file from which it can be conveniently accessed.
> 
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Andy Lutomirski <luto@amacapital.net>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Brian Gerst <brgerst@gmail.com>
> Cc: Dave Hansen <dave.hansen@intel.com>
> Cc: Denys Vlasenko <dvlasenk@redhat.com>
> Cc: H. Peter Anvin <hpa@zytor.com>
> Cc: Josh Poimboeuf <jpoimboe@redhat.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: linux-arch@vger.kernel.org
> Cc: linux-mm@kvack.org
> Suggested-by: Borislav Petkov <bp@alien8.de>
> Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
> ---
>  arch/x86/include/uapi/asm/processor-flags.h | 6 ++++++
>  arch/x86/kernel/head_32.S                   | 3 ---
>  arch/x86/kernel/head_64.S                   | 3 ---
>  3 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/x86/include/uapi/asm/processor-flags.h b/arch/x86/include/uapi/asm/processor-flags.h
> index 185f3d10c194..aae1f2aa7563 100644
> --- a/arch/x86/include/uapi/asm/processor-flags.h
> +++ b/arch/x86/include/uapi/asm/processor-flags.h
> @@ -151,5 +151,11 @@
>  #define CX86_ARR_BASE	0xc4
>  #define CX86_RCR_BASE	0xdc
>  
> +/*
> + * Initial state of CR0 for head_32/64.S
> + */

No need for that comment.

With the minor nitpicks addressed, you can add:

Reviewed-by: Borislav Petkov <bp@suse.de>

Thx.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[toc] | [next] | [standalone]


#1723796

FromRicardo Neri <ricardo.neri-calderon@linux.intel.com>
Date2017-08-31 06:10 +0200
Message-ID<ukoXL-Lg-7@gated-at.bofh.it>
In reply to#1720319
On Fri, 2017-08-25 at 19:41 +0200, Borislav Petkov wrote:

Thanks Borislav for your feedback!

> On Fri, Aug 18, 2017 at 05:27:43PM -0700, Ricardo Neri wrote:
> > Both head_32.S and head_64.S utilize the same value to initialize the
> > control register CR0. Also, other parts of the kernel might want to access
> > to this initial definition (e.g., emulation code for User-Mode Instruction
> 
> s/to //
> 
> > Prevention uses this state to provide a sane dummy value for CR0 when

I'll make this change.

> > emulating the smsw instruction). Thus, relocate this definition to a
> > header file from which it can be conveniently accessed.
> > 
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Andy Lutomirski <luto@amacapital.net>
> > Cc: Andy Lutomirski <luto@kernel.org>
> > Cc: Borislav Petkov <bp@alien8.de>
> > Cc: Brian Gerst <brgerst@gmail.com>
> > Cc: Dave Hansen <dave.hansen@intel.com>
> > Cc: Denys Vlasenko <dvlasenk@redhat.com>
> > Cc: H. Peter Anvin <hpa@zytor.com>
> > Cc: Josh Poimboeuf <jpoimboe@redhat.com>
> > Cc: Linus Torvalds <torvalds@linux-foundation.org>
> > Cc: Peter Zijlstra <peterz@infradead.org>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: linux-arch@vger.kernel.org
> > Cc: linux-mm@kvack.org
> > Suggested-by: Borislav Petkov <bp@alien8.de>
> > Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
> > ---
> >  arch/x86/include/uapi/asm/processor-flags.h | 6 ++++++
> >  arch/x86/kernel/head_32.S                   | 3 ---
> >  arch/x86/kernel/head_64.S                   | 3 ---
> >  3 files changed, 6 insertions(+), 6 deletions(-)
> > 
> > diff --git a/arch/x86/include/uapi/asm/processor-flags.h b/arch/x86/include/uapi/asm/processor-flags.h
> > index 185f3d10c194..aae1f2aa7563 100644
> > --- a/arch/x86/include/uapi/asm/processor-flags.h
> > +++ b/arch/x86/include/uapi/asm/processor-flags.h
> > @@ -151,5 +151,11 @@
> >  #define CX86_ARR_BASE	0xc4
> >  #define CX86_RCR_BASE	0xdc
> >  
> > +/*
> > + * Initial state of CR0 for head_32/64.S
> > + */
> 
> No need for that comment.
> 
> With the minor nitpicks addressed, you can add:
> 
> Reviewed-by: Borislav Petkov <bp@suse.de>

Thank you! Is it necessary for me to submit a v9 with these updates?
Perhaps I can make these updates in branch for the maintainers to pull
when/if this series is ack'ed.

Thanks and BR,
Ricardo

[toc] | [prev] | [next] | [standalone]


#1724056

FromBorislav Petkov <bp@suse.de>
Date2017-08-31 12:00 +0200
Message-ID<ukuqv-3ZB-23@gated-at.bofh.it>
In reply to#1723796
On Wed, Aug 30, 2017 at 09:04:18PM -0700, Ricardo Neri wrote:
> Thank you! Is it necessary for me to submit a v9 with these updates?
> Perhaps I can make these updates in branch for the maintainers to pull
> when/if this series is ack'ed.

Don't do anything and let me go through the rest of them first. It is
too late for this merge window anyway so we can take our time. Once you
receive full feedback from me (and hopefully others) you can send what
looks like to be a final v9 with all feedback incorporated. :-)

Thx.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[toc] | [prev] | [next] | [standalone]


#1725543

FromRicardo Neri <ricardo.neri-calderon@linux.intel.com>
Date2017-09-02 19:40 +0200
Message-ID<ulkyJ-5QR-15@gated-at.bofh.it>
In reply to#1724056
On Thu, 2017-08-31 at 11:51 +0200, Borislav Petkov wrote:
> On Wed, Aug 30, 2017 at 09:04:18PM -0700, Ricardo Neri wrote:
> > Thank you! Is it necessary for me to submit a v9 with these updates?
> > Perhaps I can make these updates in branch for the maintainers to pull
> > when/if this series is ack'ed.
> 
> Don't do anything and let me go through the rest of them first. It is
> too late for this merge window anyway so we can take our time. Once you
> receive full feedback from me (and hopefully others) you can send what
> looks like to be a final v9 with all feedback incorporated. :-)

Sure, I will wait until you (and hopefully others) are done reviewing.

Thanks and BR,
Ricardo

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web