Re: [patch 7/9] x86/iopl: Restrict iopl() permission scope

[Thomas Gleixner <tglx@linutronix.de>]

On Sun, 10 Nov 2019, Andy Lutomirski wrote:
> On Sun, Nov 10, 2019 at 12:31 PM Thomas Gleixner <tglx@linutronix.de> wrote:
> >
> > On Sun, 10 Nov 2019, Andy Lutomirski wrote:
> > > On 11/6/19 11:35 AM, Thomas Gleixner wrote:
> > > > +
> > > > +   if (IS_ENABLED(CONFIG_X86_IOPL_EMULATION)) {
> > > > +           struct tss_struct *tss;
> > > > +           unsigned int tss_base;
> > > > +
> > > > +           /* Prevent racing against a task switch */
> > > > +           preempt_disable();
> > > > +           tss = this_cpu_ptr(&cpu_tss_rw);
> > > > +           if (level == 3) {
> > > > +                   /* Grant access to all I/O ports */
> > > > +                   set_thread_flag(TIF_IO_BITMAP);
> > > > +                   tss_base = IO_BITMAP_OFFSET_VALID_ALL;
> > >
> > > Where is the actual TSS updated?
> >
> > Here. It sets the offset to the all zero bitmap. That's all it needs.
> 
> Ah, I see.
> 
> > > I think what you need to do is have a single function, called by
> > > exit_thread(), switch_to(), and here, that updates the TSS to match a
> > > given task's IO bitmap state.  This is probably switch_to_bitmap() or
> > > similar.
> >
> > Well, no. exit_thread() and this here actually fiddle with the TIF bit
> > which is not what the switch to case does. There is some stuff which can be
> > shared.
> 
> I was thinking that the code that read iopl_emul and t->io_bitmap_ptr
> and updated x86_tss.io_bitmap_base could be factored out of
> switch_to().  Suppose you call that tss_update_io_bitmap().  And you
> could have another tiny helper:
> 
> static void update_tif_io_bitmap(void)
> {
>   if (...->iopl_emul || ...->io_bitmap_ptr)
>     set_thread_flag(TIF_IO_BITMAP);
>   else
>     clear_thread_flag(TIF_IO_BITMAP);
> }
> 
> Then the whole iopl emulation path becomes:

Yes. I'm almost done with that already :)
> > It's in that very same patch:
> >
> > > -static void tss_update_io_bitmap(struct tss_struct *tss,
> > > -                                struct thread_struct *thread)
> 
> But where did the line you just deleted come from?  I'm obviously just
> bad at reading emails somewhere.

patch 5/9 :)
 
Let me finish that stuff and send out another version which has that reuse
of the switch to code in a separate patch.

There is another new detail in the series. I split out all the io bitmap
data into a separate data struct, which also allows me to stick a refcount
into it which removes the kmemdup() from the fork path.

Thanks,

	tglx