Messages in this thread | | | Date | Tue, 12 Dec 2017 19:19:02 +0100 | From | Peter Zijlstra <> | Subject | Re: [patch 13/16] x86/ldt: Introduce LDT write fault handler |
| |
On Tue, Dec 12, 2017 at 09:58:58AM -0800, Andy Lutomirski wrote: > On Tue, Dec 12, 2017 at 9:32 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> > +bool __ldt_write_fault(unsigned long address) > > +{ > > + struct ldt_struct *ldt = current->mm->context.ldt; > > + unsigned long start, end, entry; > > + struct desc_struct *desc; > > + > > + start = (unsigned long) ldt->entries; > > + end = start + ldt->nr_entries * LDT_ENTRY_SIZE; > > + > > + if (address < start || address >= end) > > + return false; > > + > > + desc = (struct desc_struct *) ldt->entries; > > + entry = (address - start) / LDT_ENTRY_SIZE; > > + desc[entry].type |= 0x01; > > You have another patch that unconditionally sets the accessed bit on > installation. What gives?
Right, initially we didn't set that unconditionally. But even when we did do that, we've observed the CPU generating these write faults.
> Also, this patch is going to die a horrible death if IRET ever hits > this condition. Or load gs.
Us touching the CS/SS descriptors with LAR should avoid IRET going off the rails, I'm not familiar with the whole gs thing, but we could very easily augment refresh_ldt_segments() I suppose.
Would you care to be a little more specific and or propose a testcase for this situation?
| |