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: Tue, 15 Dec 2020 18:09:02 -0800 From: Andy Lutomirski <luto@...nel.org> To: Ira Weiny <ira.weiny@...el.com> Cc: Andy Lutomirski <luto@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, Peter Zijlstra <peterz@...radead.org>, Dave Hansen <dave.hansen@...ux.intel.com>, X86 ML <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>, Andrew Morton <akpm@...ux-foundation.org>, Fenghua Yu <fenghua.yu@...el.com>, "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>, linux-nvdimm <linux-nvdimm@...ts.01.org>, Linux-MM <linux-mm@...ck.org>, "open list:KERNEL SELFTEST FRAMEWORK" <linux-kselftest@...r.kernel.org>, Dan Williams <dan.j.williams@...el.com>, Greg KH <gregkh@...uxfoundation.org> Subject: Re: [PATCH V3.1] entry: Pass irqentry_state_t by reference On Tue, Dec 15, 2020 at 5:32 PM Ira Weiny <ira.weiny@...el.com> wrote: > > On Fri, Dec 11, 2020 at 02:14:28PM -0800, Andy Lutomirski wrote: > > On Mon, Nov 23, 2020 at 10:10 PM <ira.weiny@...el.com> wrote: > > IOW we have: > > > > struct extended_pt_regs { > > bool rcu_whatever; > > other generic fields here; > > struct arch_extended_pt_regs arch_regs; > > struct pt_regs regs; > > }; > > > > and arch_extended_pt_regs has unsigned long pks; > > > > and instead of passing a pointer to irqentry_state_t to the generic > > entry/exit code, we just pass a pt_regs pointer. And we have a little > > accessor like: > > > > struct extended_pt_regs *extended_regs(struct pt_regs *) { return > > container_of(...); } > > > > And we tell eBPF that extended_pt_regs is NOT ABI, and we will change > > it whenever we feel like just to keep you on your toes, thank you very > > much. > > > > Does this seem reasonable? > > Conceptually yes. But I'm failing to see how this implementation can be made > generic for the generic fields. The pks fields, assuming they stay x86 > specific, would be reasonable to add in PUSH_AND_CLEAR_REGS. But the > rcu/lockdep field is generic. Wouldn't we have to modify every architecture to > add space for the rcu/lockdep bool? > > If not, where is a generic place that could be done? Basically I'm missing how > the effective stack structure can look like this: > > > struct extended_pt_regs { > > bool rcu_whatever; > > other generic fields here; > > struct arch_extended_pt_regs arch_regs; > > struct pt_regs regs; > > }; > > It seems more reasonable to make it look like: > > #ifdef CONFIG_ARCH_HAS_SUPERVISOR_PKEYS > struct extended_pt_regs { > unsigned long pkrs; > struct pt_regs regs; > }; > #endif > > And leave the rcu/lockdep bool passed by value as before (still in C). We could certainly do this, but we could also allocate some generic space. PUSH_AND_CLEAR_REGS would get an extra instruction like: subq %rsp, $GENERIC_PTREGS_SIZE or however this should be written. That field would be defined in asm-offsets.c. And yes, all the generic-entry architectures would need to get onboard. If we wanted to be fancy, we could split the generic area into initialize-to-zero and uninitialized for debugging purposes, but that might be more complication than is worthwhile.
Powered by blists - more mailing lists