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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 12 Sep 2019 21:10:44 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     "Chang S. Bae" <chang.seok.bae@...el.com>,
        linux-kernel@...r.kernel.org,
        the arch/x86 maintainers <x86@...nel.org>,
        Borislav Petkov <bp@...en8.de>, dave.hansen@...el.com,
        tony.luck@...el.com, ak@...ux.intel.com
Cc:     ravi.v.shankar@...el.com
Subject: Re: [PATCH v8 00/17] Enable FSGSBASE instructions

On 9/12/19 1:06 PM, Chang S. Bae wrote:

> Updates from v7 [7]:
> (1) Consider FSGSBASE when determining which Spectre SWAPGS mitigations are
>      required.
> (2) Fixed save_fsgs() to be aware of interrupt conditions
> (3) Made selftest changes based on Andy's previous fixes and cleanups
> (4) Included Andy's paranoid exit cleanup
> (5) Included documentation rewritten by Thomas
> (6) Carried on Thomas' edits on multiple changelogs and comments
> (7) Used '[FS|GS] base' consistently, except for selftest where GSBASE has
>      been already used in its test messages
> (8) Dropped the READ_MSR_GSBASE macro
> 

This looks unpleasant to review.  I wonder if it would be better to 
unrevert the reversion, merge up to Linus' tree or -tip, and then base 
the changes on top of that.

I also think that, before this series can have my ack, it needs an 
actual gdb maintainer to chime in, publicly, and state that they have 
thought about and tested the ABI changes and that gdb still works on 
patched kernels with and without FSGSBASE enabled.  I realize that there 
were all kinds of discussions, but they were all quite theoretical, and 
I think that the actual patches need to be considered by people who 
understand the concerns.  Specific test cases would be nice, too.

Finally, I wrote up some notes here:

https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/fixes&id=70a7d284989e3539ee84f9d709d6450099f773fb

I want to make sure that they're accounted for, and that patch should 
possibly be applied.  The parent (broken link, but should fix itself soon):

https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/fixes&id=166324e907f8a71c823b41bbc2e1b5bc711532d8

may also help understand the relevant code.

--Andy

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ