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: Tue, 16 Jun 2020 11:35:46 -0700 From: Kees Cook <keescook@...omium.org> To: Andy Lutomirski <luto@...nel.org> Cc: LKML <linux-kernel@...r.kernel.org>, Christian Brauner <christian@...uner.io>, Sargun Dhillon <sargun@...gun.me>, Tycho Andersen <tycho@...ho.ws>, Jann Horn <jannh@...gle.com>, "zhujianwei (C)" <zhujianwei7@...wei.com>, Dave Hansen <dave.hansen@...ux.intel.com>, Matthew Wilcox <willy@...radead.org>, Will Drewry <wad@...omium.org>, Shuah Khan <shuah@...nel.org>, Matt Denton <mpdenton@...gle.com>, Chris Palmer <palmer@...gle.com>, Jeffrey Vander Stoep <jeffv@...gle.com>, Aleksa Sarai <cyphar@...har.com>, Hehuazhen <hehuazhen@...wei.com>, X86 ML <x86@...nel.org>, Linux Containers <containers@...ts.linux-foundation.org>, LSM List <linux-security-module@...r.kernel.org>, Linux API <linux-api@...r.kernel.org> Subject: Re: [RFC][PATCH 0/8] seccomp: Implement constant action bitmaps On Tue, Jun 16, 2020 at 10:01:43AM -0700, Andy Lutomirski wrote: > On Tue, Jun 16, 2020 at 12:49 AM Kees Cook <keescook@...omium.org> wrote: > > > > Hi, > > > > > In order to build this mapping at filter attach time, each filter is > > executed for every syscall (under each possible architecture), and > > checked for any accesses of struct seccomp_data that are not the "arch" > > nor "nr" (syscall) members. If only "arch" and "nr" are examined, then > > there is a constant mapping for that syscall, and bitmaps can be updated > > accordingly. If any accesses happen outside of those struct members, > > seccomp must not bypass filter execution for that syscall, since program > > state will be used to determine filter action result. > > > > > During syscall action probing, in order to determine whether other members > > of struct seccomp_data are being accessed during a filter execution, > > the struct is placed across a page boundary with the "arch" and "nr" > > members in the first page, and everything else in the second page. The > > "page accessed" flag is cleared in the second page's PTE, and the filter > > is run. If the "page accessed" flag appears as set after running the > > filter, we can determine that the filter looked beyond the "arch" and > > "nr" members, and exclude that syscall from the constant action bitmaps. > > This is... evil. I don't know how I feel about it. It's also Thank you! ;) > potentially quite slow. I got the impression that (worst-case: a "full" filter for every arch/syscall combo) ~900 _local_ TLB flushes per filter attach wouldn't be very slow at all. (And the code is optimized to avoid needless flushes.) > I don't suppose you could, instead, instrument the BPF code to get at > this without TLB hackery? Or maybe try to do some real symbolic > execution of the BPF code? I think the "simple emulator" path[1] might get us a realistically large coverage. I'm going to try it out, and see what it looks like. -Kees [1] https://lore.kernel.org/lkml/202006160757.99FD9B785@keescook/ -- Kees Cook
Powered by blists - more mailing lists