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
| ||
|
Message-ID: <CAOp6jLY8aEFOOqe4ADkgeACvat+07_F_Xj963FhyXkF+0F5Pqw@mail.gmail.com> Date: Sat, 9 Dec 2023 13:59:16 +1300 From: "Robert O'Callahan" <robert@...llahan.org> To: Mark Brown <broonie@...nel.org> Cc: "Rick P. Edgecombe" <rick.p.edgecombe@...el.com>, Deepak Gupta <debug@...osinc.com>, Szabolcs Nagy <Szabolcs.Nagy@....com>, "H.J. Lu" <hjl.tools@...il.com>, Florian Weimer <fweimer@...hat.com>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>, Peter Zijlstra <peterz@...radead.org>, Juri Lelli <juri.lelli@...hat.com>, Vincent Guittot <vincent.guittot@...aro.org>, Dietmar Eggemann <dietmar.eggemann@....com>, Steven Rostedt <rostedt@...dmis.org>, Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>, Daniel Bristot de Oliveira <bristot@...hat.com>, Valentin Schneider <vschneid@...hat.com>, Christian Brauner <brauner@...nel.org>, Shuah Khan <shuah@...nel.org>, linux-kernel@...r.kernel.org, Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>, Kees Cook <keescook@...omium.org>, jannh@...gle.com, linux-kselftest@...r.kernel.org, linux-api@...r.kernel.org, David Hildenbrand <david@...hat.com> Subject: Re: [PATCH RFT v4 0/5] fork: Support shadow stacks in clone3() On Wed, 29 Nov 2023 at 07:31, Mark Brown <broonie@...nel.org> wrote: > Since clone3() is readily extensible let's add support for specifying a > shadow stack when creating a new thread or process in a similar manner > to how the normal stack is specified, keeping the current implicit > allocation behaviour if one is not specified either with clone3() or > through the use of clone(). Unlike normal stacks only the shadow stack > size is specified, similar issues to those that lead to the creation of > map_shadow_stack() apply. rr (https://rr-project.org) records program execution and then reruns it with exactly the same behavior (down to memory contents and register values). To replay clone() etc in an application using shadow stacks, we'll need to be able to ensure the shadow stack is mapped at the same address during the replay run as during the recording run. We ptrace the replay tasks and have the ability to execute arbitrary syscalls in them. It sounds like we might be able to make this work by overriding clone_args::shadow_stack_size to zero in the call to clone3(), instead having the replay task call map_shadow_stack() to put the the shadow stack in the right place, and then setting its SSP via ptrace. Will that work? Thanks, Rob -- Su ot deraeppa sah dna Rehtaf eht htiw saw hcihw, efil lanrete eht uoy ot mialcorp ew dna, ti ot yfitset dna ti nees evah ew; deraeppa efil eht. Efil fo Drow eht gninrecnoc mialcorp ew siht - dehcuot evah sdnah ruo dna ta dekool evah ew hcihw, seye ruo htiw nees evah ew hcihw, draeh evah ew hcihw, gninnigeb eht morf saw hcihw taht.
Powered by blists - more mailing lists