From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id 0FBA06EC40; Thu, 8 Jul 2021 00:59:39 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 0FBA06EC40 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1625695179; bh=pbaJGLH3OYHuzZW5OTNhfClifYFR5nW5UjspG6CWBNY=; h=Date:To:Cc:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=g7aGCVKCyPqpgFYdGmcZWEyEax4hTHeyBRv7JaYldxOEOE3lsKS+Kn4TKbgRShnX6 GbfIQ7er//Tkp1U/p9svwH18fd50WVccDywHZgYm4T6B+8rdQbm/fvcIjvTyV0U0eC t169yNIPHjVaYeDCwT7Ja4uWjcYCPfi2OXwKfOd4= Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 639696EC40 for ; Thu, 8 Jul 2021 00:59:37 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 639696EC40 Received: by mail-lf1-f52.google.com with SMTP id t17so8355764lfq.0 for ; Wed, 07 Jul 2021 14:59:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=ZC1PjB8Y6B2wtflxlpWeMLWyL9bxF2uA9bY3LAaHo7Q=; b=hheOYryA146zHO+pe6KzyY9lTP5BgFRkYJWjtj/8ZYQieoo+iKSuqZNeKyu7A5ffNU GPtjWbnOsgFbi/I1tHlPdCzs7KclY/Je97YZTtsLtqXarvPAaC7sCsZok0HBJ22JDmHS JRGipKy9JQX8Mk4dwlz62CH03BNsyGZTh3hBi3EdSbXk9rmko+SOFrG0X5NO6lzwiEMC fT9euVsVVwuTb1WqeEUqpLPGd3QN6D1jHcLBeM8PoO1Kqz+IgHaUuZkZnbEhuueM+zv2 N18pqHY+rDx5SMWdb2RoiXV9nVynOSOjvDbbQZ3ak6qHNjf11XEqKmHqRxGPrgsVrRvK +9vA== X-Gm-Message-State: AOAM531qXH80JLAbV5R6D30dlNro8u9ZCttn/qJPm8oF7eMq7gO3KbAd AmH7F9RrGvO5e0RVorzOtIYJ/ng6ePE= X-Google-Smtp-Source: ABdhPJwsyQaDTQBQloVQ5QGe23Lzg4FyR6sANnzcouFDIkgpphxtyLlQ4QyIyHpmKe/4udqoJdzQ0w== X-Received: by 2002:a19:ca0e:: with SMTP id a14mr21121802lfg.384.1625695175864; Wed, 07 Jul 2021 14:59:35 -0700 (PDT) Received: from grain.localdomain ([5.18.199.94]) by smtp.gmail.com with ESMTPSA id t17sm27904ljt.1.2021.07.07.14.59.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Jul 2021 14:59:34 -0700 (PDT) Received: by grain.localdomain (Postfix, from userid 1000) id 748175A001E; Thu, 8 Jul 2021 00:59:33 +0300 (MSK) Date: Thu, 8 Jul 2021 00:59:33 +0300 To: Vladislav Shpilevoy Cc: tml Message-ID: References: <20210625100707.87807-1-gorcunov@gmail.com> <9652278e-570e-40e5-b2d1-856fe58179fc@tarantool.org> <4b0f4d8f-4e0c-00d0-38ad-0b6abad3aafe@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.0.7 (2021-05-04) Subject: Re: [Tarantool-patches] [PATCH] raft: more precise verification of incoming request state X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Cyrill Gorcunov via Tarantool-patches Reply-To: Cyrill Gorcunov Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" On Wed, Jul 07, 2021 at 11:25:45PM +0200, Vladislav Shpilevoy wrote: > Hi! Thanks for the fixes! > > See 4 comments below. > > 1. The build does not work: > /Users/gerold/Work/Repositories/tarantool/src/box/xrow.c:1076:8: error: variable 'val' is uninitialized when used here [-Werror,-Wuninitialized] > if (val > UINT_MAX) > ^~~ > /Users/gerold/Work/Repositories/tarantool/src/box/xrow.c:1058:15: note: initialize the variable 'val' to silence this warning > uint64_t val; > ^ > = 0 Thanks! You know, I don't get why compiler is complaining here, since we use @val only after assignment val = mp_decode_uint(&pos); if (val > UINT_MAX) goto bad_vote; r->vote = val; so this is pretty weird. I'll update of course to make it compilabe for your instance but to be honest I don't understand this. > > > diff --git a/src/box/xrow.c b/src/box/xrow.c > > index 16cb2484c..75f5c94af 100644 > > --- a/src/box/xrow.c > > +++ b/src/box/xrow.c > > @@ -1064,12 +1065,17 @@ xrow_decode_raft(const struct xrow_header *row, struct raft_request *r, > > case IPROTO_RAFT_VOTE: > > if (mp_typeof(*pos) != MP_UINT) > > goto bad_msgpack; > > - r->vote = mp_decode_uint(&pos); > > + val = mp_decode_uint(&pos); > > + if (val > UINT_MAX) > > + goto bad_vote; > > + r->vote = val; > > break; > > case IPROTO_RAFT_STATE: > > if (mp_typeof(*pos) != MP_UINT) > > goto bad_msgpack; > > - r->state = mp_decode_uint(&pos); > > 2. You deleted the state decode. I assume not a single replication > test passes now, correct? Nope :) I write it back a bit later once verification is complete. I ran the test locally before sending the patch. > > > + if (val > UINT_MAX) > > 3. State and vote have uint32_t type. Please, use UINT32_MAX. UINT32_MAX is just an extension over UINT_MAX but sure, will update. > > > + goto bad_state; > > + r->state = val; Here is it written back once we know that trimming value to u32 is safe. > > --- a/src/lib/raft/raft.c > > +++ b/src/lib/raft/raft.c > > @@ -309,7 +309,8 @@ raft_process_msg(struct raft *raft, const struct raft_msg *req, uint32_t source) > > say_info("RAFT: message %s from %u", raft_msg_to_string(req), source); > > assert(source > 0); > > assert(source != raft->self); > > - if (req->term == 0 || req->state == 0 || req->state >= raft_state_MAX) { > > + > > + if (req->term == 0 || req->state <= 0 || req->state >= raft_state_MAX) { > > 4. Still, you assume you can safely assign uint32_t value to enum raft_state. > I don't think it is a good idea. What if the enum someday will become 1 byte? It won't. This will violate the C language standart. Enum has to have int type. In case if there some rare architecture where sizeof(int) = 1 then enum size will be our least problem I guarantee. > Lets not rely on its size. What was wrong with turning the enum into uint32/64 > like I proposed before? Actually there is nothing wrong with using uint instead, I thought keeping it as a former enum will be less intrusive. But sure thing, if you prefer uint I'll make it so. Gimme some time to prepare a patch then (tomorrow I think).