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


Groups > linux.kernel > #1640127 > unrolled thread

Re: [v6 PATCH 07/21] x86/insn-eval: Add utility function to get segment descriptor

Started byRicardo Neri <ricardo.neri-calderon@linux.intel.com>
First post2017-05-12 04:20 +0200
Last post2017-05-15 19:30 +0200
Articles 2 — 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: [v6 PATCH 07/21] x86/insn-eval: Add utility function to get  segment descriptor Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-05-12 04:20 +0200
    Re: [v6 PATCH 07/21] x86/insn-eval: Add utility function to get  segment descriptor Borislav Petkov <bp@suse.de> - 2017-05-15 19:30 +0200

#1640127 — Re: [v6 PATCH 07/21] x86/insn-eval: Add utility function to get segment descriptor

FromRicardo Neri <ricardo.neri-calderon@linux.intel.com>
Date2017-05-12 04:20 +0200
SubjectRe: [v6 PATCH 07/21] x86/insn-eval: Add utility function to get segment descriptor
Message-ID<tG8ls-6ft-3@gated-at.bofh.it>
On Thu, 2017-05-04 at 13:02 +0200, Borislav Petkov wrote:
> On Wed, Apr 26, 2017 at 02:51:56PM -0700, Ricardo Neri wrote:
> > > > +			     seg >= current->active_mm->context.ldt->size)) {
> > > 
> > > ldt->size is the size of the descriptor table but you've shifted seg by
> > > 3. That selector index is shifted by 3 (to the left) to form an offset
> > > into the descriptor table because the entries there are 8 bytes.
> > 
> > I double-checked the ldt code and it seems to me that size refers to the
> > number of entries in the table; it is always multiplied by
> > LDT_ENTRY_SIZE [1], [2]. Am I missing something?
> 
> No, you're not. I fell into that wrongly named struct member trap.
> 
> So ldt_struct.size should actually be called ldt_struct.n_entries or
> similar. Because what's in there is now is not "size".
> 
> And then code like
> 
> 	new_ldt->size * LDT_ENTRY_SIZE
> 
> would make much more sense if written like this:
> 
> 	new_ldt->n_entries * LDT_ENTRY_SIZE
> 
> Would you fix that in a prepatch pls?
> 

Sure I can. Would this trigger a v8 of my series? I was hoping v7 series
could be merged and then start doing incremental work on top of it. Does
it make sense?

Thanks and BR,
Ricardo

[toc] | [next] | [standalone]


#1641920

FromBorislav Petkov <bp@suse.de>
Date2017-05-15 19:30 +0200
Message-ID<tHrYL-2FM-45@gated-at.bofh.it>
In reply to#1640127
On Thu, May 11, 2017 at 07:13:57PM -0700, Ricardo Neri wrote:
> Sure I can. Would this trigger a v8 of my series? I was hoping v7 series
> could be merged and then start doing incremental work on top of it. Does
> it make sense?

I guess that's tip guys' call.

-- 
Regards/Gruss,
    Boris.

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

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web