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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 26 Nov 2017 16:58:37 +0100 From: Ingo Molnar <mingo@...nel.org> To: Andy Lutomirski <luto@...nel.org> Cc: Dave Hansen <dave.hansen@...el.com>, X86 ML <x86@...nel.org>, Borislav Petkov <bpetkov@...e.de>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Brian Gerst <brgerst@...il.com>, Linus Torvalds <torvalds@...ux-foundation.org> Subject: Re: [PATCH v2] x86/entry: Fix assumptions that the HW TSS is at the beginning of cpu_tss * Andy Lutomirski <luto@...nel.org> wrote: > On Sun, Nov 26, 2017 at 5:48 AM, Ingo Molnar <mingo@...nel.org> wrote: > > > > * Dave Hansen <dave.hansen@...el.com> wrote: > > > >> On 11/10/2017 08:05 PM, Andy Lutomirski wrote: > >> > -struct tss_struct doublefault_tss __cacheline_aligned = { > >> > - .x86_tss = { > >> > - .sp0 = STACK_START, > >> > - .ss0 = __KERNEL_DS, > >> > - .ldt = 0, > >> ... > >> > +struct x86_hw_tss doublefault_tss __cacheline_aligned = { > >> > + .sp0 = STACK_START, > >> > + .ss0 = __KERNEL_DS, > >> > + .ldt = 0, > >> > + .io_bitmap_base = INVALID_IO_BITMAP_OFFSET, > >> > >> FWIW, I really like the trend of renaming the hardware structures in > >> such a way that it's clear that they *are* hardware structures. > >> > >> It might also be nice to reference the relevant SDM sections on the > >> topic, or even to include a comment along the lines of how it get used. > >> This chunk from the SDM is particularly relevant: > >> > >> "The TSS holds information important to 64-bit mode and that is not > >> directly related to the task-switch mechanism." > > > > That makes sense - I've updated this patch with the following description added to > > struct x86_hw_tss: > > I've folded this in along with all the reviews so far, and a few misc > fixes from Boris' review. I was planning to resend the whole series > today after I track down the kbuild error. Does that sound good? Could you please do a delta to the very latest WIP.x86/mm instead? In the latest I have included the review tags already, and all the easy-to-do review feedback as well, so the delta should be rasonably small. These entry bits are destined for x86/urgent real soon, so Thomas and me are trying to pin the tree down and do delta changes only. If it's a simple full interdiff between your latest and WIP.x86/mm that's fine as well, can backmerge everything accordingly. Thanks, Ingo
Powered by blists - more mailing lists