On Fri, Sep 18, 2020 at 2:17 PM Dave Hansen <dave.hansen@xxxxxxxxx> wrote: > > On 9/18/20 2:06 PM, H.J. Lu wrote: > > On Fri, Sep 18, 2020 at 2:00 PM Pavel Machek <pavel@xxxxxx> wrote: > >> On Fri 2020-09-18 12:32:57, Dave Hansen wrote: > >>> On 9/18/20 12:23 PM, Yu-cheng Yu wrote: > >>>> Emulation of the legacy vsyscall page is required by some programs > >>>> built before 2013. Newer programs after 2013 don't use it. > >>>> Disable vsyscall emulation when Control-flow Enforcement (CET) is > >>>> enabled to enhance security. > >>> How does this "enhance security"? > >>> > >>> What is the connection between vsyscall emulation and CET? > >> Boom. > >> > >> We don't break compatibility by default, and you should not tell > >> people to enable CET by default if you plan to do this. > >> > > Nothing will be broken. CET enabled applications don't use/need > > vsyscall emulation. > > Hi H.J., > > Could you explain your logic a bit more thoroughly, please? Here is my CET slides for LPC 2020: https://gitlab.com/cet-software/cet-smoke-test/-/wikis/uploads/09431a51248858e6f716a59065d732e2/CET-LPC-2020.pdf which may have answers for most questions. > I also suspect that Pavel was confused by your changelog where you said > that you do this when "CET is enabled". Does enabled in this context mean: > 1. Just CET support compiled in, or > 2. Compiled in and on CET hardware, or > 3. Compiled in to the kernel enabled in the app and running on CET > hardware? CET is enabled only in a process if 1. All components are CET enabled, and 2. CPU supports CET, and 3. Kernel supports CET. -- H.J.
