linux-kernel - Re: [patch 5/9] x86/ioport: Reduce ioperm impact for sane usage further

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 7 Nov 2019 08:37:20 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
        Stephen Hemminger <stephen@...workplumber.org>,
        Willy Tarreau <w@....eu>, Juergen Gross <jgross@...e.com>,
        Sean Christopherson <sean.j.christopherson@...el.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [patch 5/9] x86/ioport: Reduce ioperm impact for sane usage
 further


* Thomas Gleixner <tglx@...utronix.de> wrote:

> @@ -365,19 +365,19 @@ struct tss_struct {
>  	struct x86_hw_tss	x86_tss;
>  
>  	/*
> -	 * Store the dirty size of the last io bitmap offender. The next
> -	 * one will have to do the cleanup as the switch out to a non
> -	 * io bitmap user will just set x86_tss.io_bitmap_base to a value
> -	 * outside of the TSS limit. So for sane tasks there is no need
> -	 * to actually touch the io_bitmap at all.
> +	 * Store the dirty byte range of the last io bitmap offender. The
> +	 * next one will have to do the cleanup because the switch out to a
> +	 * non I/O bitmap user will just set x86_tss.io_bitmap_base to a
> +	 * value outside of the TSS limit to not penalize tasks which do
> +	 * not use the I/O bitmap at all.
>  	 */
> -	unsigned int		io_bitmap_prev_max;
> +	unsigned int		io_zerobits_start;
> +	unsigned int		io_zerobits_end;
>  
>  	/*
> -	 * The extra 1 is there because the CPU will access an
> -	 * additional byte beyond the end of the IO permission
> -	 * bitmap. The extra byte must be all 1 bits, and must
> -	 * be within the limit.
> +	 * The extra 1 is there because the CPU will access an additional
> +	 * byte beyond the end of the I/O permission bitmap. The extra byte
> +	 * must have all bits set and must be within the TSS limit.
>  	 */
>  	unsigned long		io_bitmap[IO_BITMAP_LONGS + 1];
>  } __aligned(PAGE_SIZE);

Note that on 32-bit kernels this blows up our CPU area calculations:

./include/linux/compiler.h:350:38: error: call to ‘__compiletime_assert_181’ declared with attribute error: BUILD_BUG_ON failed: CPU_ENTRY_AREA_PAGES * PAGE_SIZE < CPU_ENTRY_AREA_MAP_SIZE
./include/linux/compiler.h:331:4: note: in definition of macro ‘__compiletime_assert’
./include/linux/compiler.h:350:2: note: in expansion of macro ‘_compiletime_assert’
./include/linux/build_bug.h:39:37: note: in expansion of macro ‘compiletime_assert’
./include/linux/build_bug.h:50:2: note: in expansion of macro ‘BUILD_BUG_ON_MSG’
arch/x86/mm/cpu_entry_area.c:181:2: note: in expansion of macro ‘BUILD_BUG_ON’
make[2]: *** [scripts/Makefile.build:265: arch/x86/mm/cpu_entry_area.o] Error 1

Thanks,

	Ingo