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
| ||
|
Date: Wed, 1 Jun 2022 17:27:44 +0000 From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com> To: "hjl.tools@...il.com" <hjl.tools@...il.com> CC: "bsingharora@...il.com" <bsingharora@...il.com>, "hpa@...or.com" <hpa@...or.com>, "Syromiatnikov, Eugene" <esyr@...hat.com>, "peterz@...radead.org" <peterz@...radead.org>, "rdunlap@...radead.org" <rdunlap@...radead.org>, "keescook@...omium.org" <keescook@...omium.org>, "0x7f454c46@...il.com" <0x7f454c46@...il.com>, "Eranian, Stephane" <eranian@...gle.com>, "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>, "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>, "linux-mm@...ck.org" <linux-mm@...ck.org>, "adrian@...as.de" <adrian@...as.de>, "fweimer@...hat.com" <fweimer@...hat.com>, "nadav.amit@...il.com" <nadav.amit@...il.com>, "jannh@...gle.com" <jannh@...gle.com>, "avagin@...il.com" <avagin@...il.com>, "kcc@...gle.com" <kcc@...gle.com>, "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>, "pavel@....cz" <pavel@....cz>, "oleg@...hat.com" <oleg@...hat.com>, "bp@...en8.de" <bp@...en8.de>, "Lutomirski, Andy" <luto@...nel.org>, "Yang, Weijiang" <weijiang.yang@...el.com>, "arnd@...db.de" <arnd@...db.de>, "Moreira, Joao" <joao.moreira@...el.com>, "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>, "tglx@...utronix.de" <tglx@...utronix.de>, "mike.kravetz@...cle.com" <mike.kravetz@...cle.com>, "x86@...nel.org" <x86@...nel.org>, "rppt@...nel.org" <rppt@...nel.org>, "john.allen@....com" <john.allen@....com>, "dave.martin@....com" <dave.martin@....com>, "mingo@...hat.com" <mingo@...hat.com>, "Hansen, Dave" <dave.hansen@...el.com>, "corbet@....net" <corbet@....net>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "gorcunov@...il.com" <gorcunov@...il.com>, "Shankar, Ravi V" <ravi.v.shankar@...el.com>, "linux-api@...r.kernel.org" <linux-api@...r.kernel.org> Subject: Re: [PATCH 00/35] Shadow stacks for userspace On Tue, 2022-05-31 at 11:00 -0700, H.J. Lu wrote: > > The glibc logic seems wrong to me also, because shadow stack or IBT > > could be force-disabled via glibc tunables. I don't see why the elf > > header bit should exclusively control the feature locking. Or why > > both > > should be locked if only one is in the header. > > glibc locks SHSTK and IBT only if they are enabled at run-time. It's not what I saw in the code. Somehow Mike saw something different as well. > It doesn't > enable/disable/lock WRSS at the moment. If WRSS can be enabled > via arch_prctl at any time, we can't lock it. If WRSS should be > locked early, > how should it be enabled in application? Also can WRSS be enabled > from a dlopened object? I think in the past we discussed having another elf header bit that behaved differently (OR vs AND).
Powered by blists - more mailing lists