Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36;
MIME-Version: 1.0
References: <CAADnVQJ4Fg-VQ-tVCEqsKLuozT7y_o8pZ1oM3eBW7u-Z0jOk4A@mail.gmail.com>
 <20230918112549.105846-1-gerhorst@amazon.de>
In-Reply-To: <20230918112549.105846-1-gerhorst@amazon.de>
From:   Alexei Starovoitov <alexei.starovoitov@gmail.com>
Date:   Tue, 19 Sep 2023 01:57:21 -0700
Message-ID: <CAADnVQJZRqNZ_rKw2tUrmDpwhW7JGUge1+9x1_qtROf=OyMpHw@mail.gmail.com>
Subject: Re: [PATCH 2/3] Revert "bpf: Fix issue in verifying allow_ptr_leaks"
To:     Luis Gerhorst <gerhorst@amazon.de>
Cc:     Andrii Nakryiko <andrii@kernel.org>,
        Alexei Starovoitov <ast@kernel.org>, bpf <bpf@vger.kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>,
        Luis Gerhorst <gerhorst@cs.fau.de>,
        Hagar Gamal Halim Hemdan <hagarhem@amazon.de>,
        Hao Luo <haoluo@google.com>,
        Ilya Leoshkevich <iii@linux.ibm.com>,
        John Fastabend <john.fastabend@gmail.com>,
        Jiri Olsa <jolsa@kernel.org>, KP Singh <kpsingh@kernel.org>,
        Yafang Shao <laoar.shao@gmail.com>,
        LKML <linux-kernel@vger.kernel.org>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@vger.kernel.org>,
        Martin KaFai Lau <martin.lau@linux.dev>,
        Mykola Lysenko <mykolal@fb.com>,
        Puranjay Mohan <puranjay12@gmail.com>,
        Stanislav Fomichev <sdf@google.com>,
        Shuah Khan <shuah@kernel.org>, Song Liu <song@kernel.org>,
        Yonghong Song <yonghong.song@linux.dev>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Mon, Sep 18, 2023 at 4:26=E2=80=AFAM Luis Gerhorst <gerhorst@amazon.de> =
wrote:
>
> It is true that this is not easily possible using the method most exploit=
s use,
> at least to my knowledge (i.e., accessing the same address from another c=
ore).
> However, it is still possible to evict the cacheline with skb->data/data_=
end
> from the cache in between the loads by iterating over a large map using
> bpf_loop(). Then the load of skb->data_end would be slow while skb->data =
is
> readily available in a callee-saved register.

...

> call %[bpf_loop]; \
> gadget_%=3D: \
> r2 =3D *(u32 *)(r7 + 80);   \
> if r2 <=3D r9 goto exit_%=3D; \

r9 is supposed to be available in the callee-saved register? :)
I think you're missing that it is _callee_ saved.
If that bpf_loop indeed managed to flush L1 cache the
refill of r9 in the epilogue would be a cache miss.
And r7 will be a cache miss as well.
So there is no chance cpu will execute 'if r2 <=3D r9' speculatively.

I have to agree that the above approach sounds plausible in theory
and I've never seen anyone propose to mispredict a branch
this way. Which also means that no known speculation attack
was crafted. I suspect that's a strong sign that
the above approach is indeed a theory and it doesn't work in practice.
Likely because the whole cache is flushed the subsequent misses
will spoil all speculation. For spec v1 to work you need
only one slow load in one side of that branch.
The other load and the speculative code after should not miss.
When it does the spec code won't be able to leave the breadcrumbs
of the leaked bit in the cache.
'Leak full byte' is also 'wishful thinking' imo.
I haven't seen any attack that leaks byte at-a-time.

So I will insist on seeing a full working exploit before doing
anything else here. It's good to discuss this cpu speculation
concerns, but we have to stay practical.
Even removing bpf from the picture there is so much code
in the network core that checks packet boundaries.
One can find plenty of cases of 'read past skb->end'
under speculation and I'm arguing none of them are exploitable.