Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2;
Date:   Fri, 13 Oct 2023 11:27:56 +0800
From:   Shung-Hsi Yu <shung-hsi.yu@suse.com>
To:     Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc:     Hao Sun <sunhao.th@gmail.com>, Alexei Starovoitov <ast@kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>,
        John Fastabend <john.fastabend@gmail.com>,
        Andrii Nakryiko <andrii@kernel.org>,
        Martin KaFai Lau <martin.lau@linux.dev>,
        Song Liu <song@kernel.org>,
        Yonghong Song <yonghong.song@linux.dev>,
        KP Singh <kpsingh@kernel.org>,
        Stanislav Fomichev <sdf@google.com>,
        Hao Luo <haoluo@google.com>, Jiri Olsa <jolsa@kernel.org>,
        bpf <bpf@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH bpf-next v3 1/3] bpf: Detect jumping to reserved code
 during check_cfg()
Message-ID: <ZSi5PHDfoAYcvbCq@u94a>
References: <20231011-jmp-into-reserved-fields-v3-0-97d2aa979788@gmail.com>
 <20231011-jmp-into-reserved-fields-v3-1-97d2aa979788@gmail.com>
 <CAADnVQJnhfbALtNkCauS_ZwRfybcb_mryEvZW7Uu1uOSshQ9Ew@mail.gmail.com>
 <ZSeq7ieG7Cq13w67@u94a>
 <CAADnVQJHAPid9HouwMEnfwDDKuy8BnGia269KSbby2gA030OBg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAADnVQJHAPid9HouwMEnfwDDKuy8BnGia269KSbby2gA030OBg@mail.gmail.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MFRtK25seERlMW5ySmZnNlFUQTNOdEFVMmdjVkFaQ3IwdFQ4a0owZGcrK3dW?=
 =?utf-8?B?ZmJUYkF0bTJOM0pvVGZzM25WeGpEdVk4eVJ1N3pGWVl0UDU2VzZYY3BNNUxt?=
 =?utf-8?B?anFrYkVWR3BvNUR6ZFBFWUk0dzNLMXdEMTI3YWdETndxbjAwTTlmaGdPSnc2?=
 =?utf-8?B?WkhQK1Z4QkxCSHJsajZ0aWVtak5ZdC8vSCtYSnhhZEpQSXFPeUJhQnFHNEo1?=
 =?utf-8?B?YTB2N0VMV3R2YnNWL1hHNVZpcjRRZWppa2twcFhDV1dINkdNN3JMWFFEeE5j?=
 =?utf-8?B?MUZ6VFdwZWJqcGF6YW1BZUxLTHUzdU1vd3VGeXhrNHQ5SFA0MW1EcDlWMnlv?=
 =?utf-8?B?T3BqYys5SXBmZCtqS3ZvQUhOSnRzN0ZJNldGZERBbldINkVjQklIT2hBcGZj?=
 =?utf-8?B?MGl2ckRKckZQcWlvMVhyK3hYOEtML0x5N1ZRNGVyL202SGdwQzd1YVlQeFZa?=
 =?utf-8?B?TjEwVE5uQ2prNHI4N3k0ZndDY1h4eUwxY0FiQ3lUYXlWZTJONTl4dVZ5UFhZ?=
 =?utf-8?B?cEQzMm96VDEzNmdmUjlQVDB4Y3oxaXNlMTFKc2c0S3h4VzRDRS9nQTdxcmJo?=
 =?utf-8?B?aUxqb2VGWUF1TktTQWxGMndyTGowWWJ1UkhSOFNoN2xzTktwNC9VM0V1WmRR?=
 =?utf-8?B?RUFuZ2krM0N6dHFGazVTNjNrejg1UmhmeTNWMitLRlhrTG1kd3VpSEMyU21Y?=
 =?utf-8?B?TWNQYnNReStCQXhtUHBkcUoxWUx1MHhRRDNkeG5TNndBNG8ydmJETDBTOGpI?=
 =?utf-8?B?dm9HQVdaT2w0VXM1SjdkMWdvajRhNFowSTRzbDRyMnlYd3VtZnZDVGVzTWY5?=
 =?utf-8?B?a1FKMkpJUTZGWlc3R1JnTG4wSW5CV29KWmRvZzlUZzBHMGV3YjRJejJOdWxi?=
 =?utf-8?B?aFAzeStvUFppYjVkSjVhdmpKMDhaQnJ1T0FEVXpuc01iSHFBeXU2aDkzV3V6?=
 =?utf-8?B?VTJ5ZUlzTVhucmxQbUs3SG80WDBVdDIvczdTMXNMQUltaVAyUW9KS3M0N3Fz?=
 =?utf-8?B?MG5lZk5DRXdSeFM0N3J3NVo5RXE1VEk0bUhYSFA4YnVBVkpVRlNoZWRsWVZk?=
 =?utf-8?B?MEhKTzJENGhnL2FIUm43UzM3UC9VQzZiUTJRZU5aU3V4b2V4UWkzMGI0Q0sy?=
 =?utf-8?B?d2JyM0gzUCtZWU9vOEtjMnppM2dERnZkcEdRK3F3Q1BibTdCYktpRk9UK29m?=
 =?utf-8?B?Y2NNYS9DYU5DeFB0R09QMlZsM1RDK2lXN3dHQjJjTUZJNTJMdTZIdVFDMmN1?=
 =?utf-8?B?WS9BQWFYVDBGS0N6Zi9uWW5RZ1VVYWFnbGJ5OG9wb0IxRXlPTStrYTMzdE4r?=
 =?utf-8?B?bjU4MzFvdWkxYTFlcjdMRi9JN1hSTE9xYzYrcGt1NmU0TUtUNGtVZ2h0Nnl2?=
 =?utf-8?B?VlZxNXFxSWVjMDBTRTBvU093YWs4dFhSaTRFQmcrbmRQUlBCaW52VEh5c0dF?=
 =?utf-8?B?OE5iR2wxc3RQZWt3RnVuL2RUcGFlTDlIZkJuM3A0a1d4NGhxZUVZNFVFUWRU?=
 =?utf-8?B?K0puaVRSYXFpSGtWMjhZOHZrSmF1SFo0RE5BWUtBa1R6b0pGTEkyVkJXR0Rq?=
 =?utf-8?B?aCs1WFNvY0FudzB4TDNwdUFTQjF2UW1PeDNjUVhmM01uMFYxTUdOR2U0RDEy?=
 =?utf-8?B?UzM2MENGdGIzZUo0TElUS3lFVWU5ejZkcXZjQWtMaHlZancxM0pORjRvRU5I?=
 =?utf-8?B?cERsUWVTVzRQTG1rN1ZtRlFMWG5jQWpvQXdlWmVqSUpzYVRneE9iV3pxU1FT?=
 =?utf-8?B?RFhBSEk3dmRUdkR1Rkpsa0RYMDRibUtGeFVQbnd4QjdWZHNUZjRsblpuOTVD?=
 =?utf-8?B?RWRBTys5V0dXOCt3ektPUjllTCtEV2pGeGFhNVhMSHNTM0o4OXI5REsrUGZ4?=
 =?utf-8?B?YUF3d09jdHFqMVlCZlJnZUQ1NWFtQlRWb0ZYMWtPdy9hUnExVGVxTmVmOGpn?=
 =?utf-8?B?ZUduTHdqTkk3V25nK3prNFpuanR1NU5TV3E2Zy9yMnJXQjNWQ2ZuRUVDRkgv?=
 =?utf-8?B?cUlsZlAyV1ZLdWFwYy9vSFRBcVR5Y0Rwek5lZS96RndEdjZzelptL2ExMlRW?=
 =?utf-8?B?NHU1NFpxMW1qZC83Nm5GTnFKL25ZVnZPUXpzOGhST3NublJ0clZLSzduWW9L?=
 =?utf-8?Q?wciKUfHq1RxEBvsujU65aRvBp?=
X-OriginatorOrg: suse.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9bdce4ab-cc3e-4aa4-2770-08dbcb9c6964
X-MS-Exchange-CrossTenant-AuthSource: AS8PR04MB9510.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Oct 2023 03:28:05.1051
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: f7a17af6-1c5c-4a36-aa8b-f5be247aa4ba
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: svg0UbEhClESfwdxkDLg51Cm1+ei7YkdQ8/5kVt9Z/veblJt1WkZUg5jzJbACm9NbKYQQy7TB/xo0+lTYGw6IQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR04MB8227
X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no
	version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Thu, 12 Oct 2023 20:28:20 -0700 (PDT)

On Thu, Oct 12, 2023 at 08:02:00AM -0700, Alexei Starovoitov wrote:
> On Thu, Oct 12, 2023 at 1:14 AM Shung-Hsi Yu <shung-hsi.yu@suse.com> wrote:
> > On Wed, Oct 11, 2023 at 06:38:56AM -0700, Alexei Starovoitov wrote:
> > > On Wed, Oct 11, 2023 at 2:01 AM Hao Sun <sunhao.th@gmail.com> wrote:
> > > >
> > > > Currently, we don't check if the branch-taken of a jump is reserved code of
> > > > ld_imm64. Instead, such a issue is captured in check_ld_imm(). The verifier
> > > > gives the following log in such case:
> > > >
> > > > func#0 @0
> > > > 0: R1=ctx(off=0,imm=0) R10=fp0
> > > > 0: (18) r4 = 0xffff888103436000       ; R4_w=map_ptr(off=0,ks=4,vs=128,imm=0)
> > > > 2: (18) r1 = 0x1d                     ; R1_w=29
> > > > 4: (55) if r4 != 0x0 goto pc+4        ; R4_w=map_ptr(off=0,ks=4,vs=128,imm=0)
> > > > 5: (1c) w1 -= w1                      ; R1_w=0
> > > > 6: (18) r5 = 0x32                     ; R5_w=50
> > > > 8: (56) if w5 != 0xfffffff4 goto pc-2
> > > > mark_precise: frame0: last_idx 8 first_idx 0 subseq_idx -1
> > > > mark_precise: frame0: regs=r5 stack= before 6: (18) r5 = 0x32
> > > > 7: R5_w=50
> > > > 7: BUG_ld_00
> > > > invalid BPF_LD_IMM insn
> > > >
> > > > Here the verifier rejects the program because it thinks insn at 7 is an
> > > > invalid BPF_LD_IMM, but such a error log is not accurate since the issue
> > > > is jumping to reserved code not because the program contains invalid insn.
> > > > Therefore, make the verifier check the jump target during check_cfg(). For
> > > > the same program, the verifier reports the following log:
> > > >
> > > > func#0 @0
> > > > jump to reserved code from insn 8 to 7
> > > >
> > > > Signed-off-by: Hao Sun <sunhao.th@gmail.com>
> > > > ---
> > > >  kernel/bpf/verifier.c | 7 +++++++
> > > >  1 file changed, 7 insertions(+)
> > > >
> > > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > > > index eed7350e15f4..725ac0b464cf 100644
> > > > --- a/kernel/bpf/verifier.c
> > > > +++ b/kernel/bpf/verifier.c
> > > > @@ -14980,6 +14980,7 @@ static int push_insn(int t, int w, int e, struct bpf_verifier_env *env,
> > > >  {
> > > >         int *insn_stack = env->cfg.insn_stack;
> > > >         int *insn_state = env->cfg.insn_state;
> > > > +       struct bpf_insn *insns = env->prog->insnsi;
> > > >
> > > >         if (e == FALLTHROUGH && insn_state[t] >= (DISCOVERED | FALLTHROUGH))
> > > >                 return DONE_EXPLORING;
> > > > @@ -14993,6 +14994,12 @@ static int push_insn(int t, int w, int e, struct bpf_verifier_env *env,
> > > >                 return -EINVAL;
> > > >         }
> > > >
> > > > +       if (e == BRANCH && insns[w].code == 0) {
> > > > +               verbose_linfo(env, t, "%d", t);
> > > > +               verbose(env, "jump to reserved code from insn %d to %d\n", t, w);
> > > > +               return -EINVAL;
> > > > +       }
> > >
> > > I don't think we should be changing the verifier to make
> > > fuzzer logs more readable.
> >
> > Taking fuzzer out of consideration, giving users clearer explanation for
> > such verifier rejection could save a lot of head scratching.
> 
> Users won't see such errors unless they are actively doing what
> is not recommended.
> 
> > Compiler shouldn't generate such program, but its plausible to forget to
> > account that BPF_LD_IMM64 consists of two instructions when writing
> > assembly (especially with filter.h-like macros) and have it jump to the 2nd
> > part of BPF_LD_IMM64.
> 
> Using macros to write bpf asm code is highly discouraged.
> All kinds of errors are possible.
> Bogus jump is just one of such mistakes.
> Use naked functions and inline asm in C code that
> both GCC and clang understand then you won't see bad jumps.
> See selftets/bpf/verifier_*.c as an example.

Understood, thanks for the explanation!

Found them under progs/verifier_*.c inside the bpf selftest directory.

> > > Same with patch 2. The code is fine as-is.
> >
> > The only way BPF_SIZE(insn->code) != BPF_DW conditional in check_ld_imm()
> > can be met right now is when we have a jump to the 2nd part of LD_IMM64; but
> > what this conditional actually guard against is not straight-forward and
> > quite confusing[1].
> 
> There are plenty of cases in the verifier where we print
> an error message. Some of them should be impossible due
> to prior checks. In such cases we don't yell "verifier bug"
> and are not going to do that in this case either.

I agree, without patch 1 applied, the change to "verfier bug" in patch 2
doesn't make sense and is just wrong. The point I'm trying to make is that
the checks done by verifier are generally clear, you can make sense of why
certain check are in place just by looking at the code, but
BPF_SIZE(insn->code) != BPF_DW is _not_ one of them.

I got confused, (reading between the lines I believe) this had Hao puzzled,
and even Yongsong had to look twice[1] back then; so this check is certainly
not on-par with others we have in the verifier in terms of clarity, which
leads to patches here as well as mine a while back.

Perhaps we could reconsider making it more obvious how verifier prevents
jump to reserved code/2nd instruction of LD_IMM64?


1: the same https://lore.kernel.org/bpf/0cf50c32-ab67-ef23-7b84-ef1d4e007c33@fb.com/