linux-kernel - Re: [PATCH V4 00/20] The Runtime Verification (RV) interface

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPhsuW67decxVH4n4YitkW40OmUqq2LRX7Ry4jqdjrgXSAgknA@mail.gmail.com>
Date:   Thu, 23 Jun 2022 10:52:12 -0700
From:   Song Liu <song@...nel.org>
To:     Daniel Bristot de Oliveira <bristot@...nel.org>
Cc:     Steven Rostedt <rostedt@...dmis.org>,
        Wim Van Sebroeck <wim@...ux-watchdog.org>,
        Guenter Roeck <linux@...ck-us.net>,
        Jonathan Corbet <corbet@....net>,
        Ingo Molnar <mingo@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Will Deacon <will@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Marco Elver <elver@...gle.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        Shuah Khan <skhan@...uxfoundation.org>,
        Gabriele Paoloni <gpaoloni@...hat.com>,
        Juri Lelli <juri.lelli@...hat.com>,
        Clark Williams <williams@...hat.com>,
        Linux Doc Mailing List <linux-doc@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        linux-trace-devel <linux-trace-devel@...r.kernel.org>
Subject: Re: [PATCH V4 00/20] The Runtime Verification (RV) interface

On Thu, Jun 23, 2022 at 9:42 AM Daniel Bristot de Oliveira
<bristot@...nel.org> wrote:
>
> On 6/22/22 09:24, Song Liu wrote:
> > This is interesting work!
> >
> > I applied the series on top of commit 78ca55889a549a9a194c6ec666836329b774ab6d
> > in upstream. Then, I got some compile/link error for CONFIG_RV_MON_WIP and
> > CONFIG_RV_MON_SAFE_WTD. I was able to compile the kernel with these two
> > configs disabled.
>
> I rebased the code and... it compiled. Maybe it was missing some
> config options that I forgot to set as "depends on" in the Kconfig.
>
> Can you check if it was the same problem automatically reported?
>
> Any further information here would help. I will revisit this.

Here are the error messages I got: https://pastebin.com/zJxMA6RK , and
attached is the config file I used.

>
> However, I hit the some issue with monitors/wwnr/enabled :
> >
> >     [root@...50-1 ~]# cd /sys/kernel/debug/tracing/rv/
> >     [root@...50-1 rv]# cat available_monitors
> >     wwnr
> >     [root@...50-1 rv]# echo wwnr > enabled_monitors
> >     [root@...50-1 rv]# cd monitors/
> >     [root@...50-1 monitors]# cd wwnr/
> >     [root@...50-1 wwnr]# ls
> >     desc  enable  reactors
> >     [root@...50-1 wwnr]# cat enable
> >     1
> >     [root@...50-1 wwnr]# echo 0 > enable   <<< hangs
> >
> > The last echo command hangs forever on a qemu vm. I haven't figured out why
> > this happens though.
>
> I could reproduce it. It is an error in the return code of monitor_enable_write_data(),
> I fixed it locally (return retval ? retval : count; // needs more test), and
> will add it to the next version. Thanks!
>
> > I also have a more general question: can we do RV with BPF and simplify the
> > work? AFAICT, the idea of RV is to maintain a state machine based on events.
> > If something unexpected happens, call the reactor.
> >
> > IIUC, BPF has most of these building blocks ready for use. With BPF, we
> > can ship many RV monitors without much kernel changes.
>
> I am aware of bpftrace and bpf + libbpf, and I have a PoC tool doing most of the
> work I do in C/kernel in C/bpf.
>
> From the cover letter:
>
> "Things kept for a second moment (after this patchset):
> [...]
>         - dot2bpf"
>
> The point is that there are use-cases in which the users need the code in
> C. One of those is the work being done in the Linux Foundation Elisa group.
> There will be more formalism, like timed automata... which will require
> infra-structure that is easily accessible in C... including synchronization,
> and reactors that are available only in C on "per use-cases" basis - for
> example on embedded devices.

Where can I find more information about the constraints of these use cases?
I am asking because there are multiple ways to load a BPF program to the
system. If the constraint is that we cannot have bpftrace or bcc in the system,
maybe it is ok to run a standalone binary (written in C, compiled on a different
system). Or maybe we can load BPF programs in a kernel module, or compile
the BPF programs into the kernel? (Yes, we can do it now, check
kernel/bpf/preload). If any of these works, we can benefit from the good
properties of BPF. For example, we can update the RV models without
rebooting the system; and we can reuse various BPF maps, so we don't
need to add union rv_task_monitor to task_struct.

Of course, we are out of luck if these systems cannot enable CONFIG_BPF
at all. But I guess this is not common for modern embedded systems?

Thanks,
Song

Download attachment "rv.config" of type "application/octet-stream" (114828 bytes)