From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6AFC2A034F; Tue, 12 Oct 2021 00:15:52 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 08415410E8; Tue, 12 Oct 2021 00:15:52 +0200 (CEST) Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) by mails.dpdk.org (Postfix) with ESMTP id A9DC84067C for ; Tue, 12 Oct 2021 00:15:50 +0200 (CEST) Received: by mail-pl1-f179.google.com with SMTP id g9so1781515plo.12 for ; Mon, 11 Oct 2021 15:15:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=R29M9588+0Bnd1OfK0vssCV7RUxm6dBeWrFgyvcP2q8=; b=FhbVepRdyFPgl8RyVScNTr5QVS/4mokwfH0RaHFLtGGlSotZ4I6U+0EZDph3Kg7nsD RWSPD7sJtcbmXUH+/QaX7Ubd501vVrKinpx/sEaHK98W3TnEumJx8v1kh5g3sZFkJfxO JO5COmXxB2l8ZRtf8qRpAXb0boJyL+hYwz1JN/b8w8ABaUMf0KS96Dw76nIzAaAgXcGD /OvR2OKblYkvwEIjV4DGAkc0+6VgaKbwB5qMzoGNdfcj3kg70nEsEWFMqQXoYEwPopRX 5bafxr7qMxBwWfHjYRQqHEsKVb1LTJOyD7FVVc4OuvdRUxPymIj5lTdGJto9yyC1wsWb ogxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=R29M9588+0Bnd1OfK0vssCV7RUxm6dBeWrFgyvcP2q8=; b=TQIdjnPsCeqcuqEfBj1tCZn0RMbGs1vmZBz/byy3o1zyJcGugYAftLE4DIaCuRdkHm usNV5y7+5g2y1NAtZZUtgekUkuXrtOPyPjeQe2BI15Zb+Vv80KLTrNwfVPB0EDvGFOyC z7IAQ+pXQYUIFj8Pi3XH1gXcf2VuxBA6xhwUB/OOoaDbNhOYzVrlqETkz+L63+N8Zt3e 6jeezcBU37HoH/w53lDe5r8JWWbEgX6nJabxe//FIvwfC4aBL47vkb4LirIz5IvQH0b7 pVKImqtRnWpoc9zDXJ2Nx+bHL+j0a/mvZ0Dg+qpRjJa/XXY/ER1C0gbqOZz/DpTGBer6 OfDg== X-Gm-Message-State: AOAM531MvtFrSPk9ndeWnXVkYAmq3PP4XrEDBxexMb6mn8xkrnYLjJkc uxSRQmkGYIeckxOBAuxijXKQ5Q== X-Google-Smtp-Source: ABdhPJwIgKKyb6aCUHpF9EGvZbuvDerlWwIlCGk8+ABaCHN8t02iTzxhq5Ip3fDb5+Tcwdp9jZeLNw== X-Received: by 2002:a17:903:1c6:b0:13f:2b8:afe8 with SMTP id e6-20020a17090301c600b0013f02b8afe8mr27164613plh.81.1633990549883; Mon, 11 Oct 2021 15:15:49 -0700 (PDT) Received: from hermes.local (204-195-33-123.wavecable.com. [204.195.33.123]) by smtp.gmail.com with ESMTPSA id z68sm5332217pgz.90.2021.10.11.15.15.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Oct 2021 15:15:49 -0700 (PDT) Date: Mon, 11 Oct 2021 15:15:46 -0700 From: Stephen Hemminger To: Akhil Goyal Cc: Thomas Monjalon , "dev@dpdk.org" , "david.marchand@redhat.com" , "hemant.agrawal@nxp.com" , Anoob Joseph , "pablo.de.lara.guarch@intel.com" , "fiona.trahe@intel.com" , "declan.doherty@intel.com" , "matan@nvidia.com" , "g.singh@nxp.com" , "roy.fan.zhang@intel.com" , "jianjay.zhou@huawei.com" , "asomalap@amd.com" , "ruifeng.wang@arm.com" , "konstantin.ananyev@intel.com" , "radu.nicolau@intel.com" , "ajit.khaparde@broadcom.com" , Nagadheeraj Rottela , Ankur Dwivedi , "ciara.power@intel.com" , "ray.kinsella@intel.com" , "bruce.richardson@intel.com" Message-ID: <20211011151546.3c5fffbb@hermes.local> In-Reply-To: References: <20210731181327.660296-1-gakhil@marvell.com> <20211008204516.3497060-1-gakhil@marvell.com> <20211008204516.3497060-3-gakhil@marvell.com> <2663373.9MILaYa0Np@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [EXT] Re: [PATCH v2 3/3] security: add reserved bitfields X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Mon, 11 Oct 2021 16:58:24 +0000 Akhil Goyal wrote: > > 08/10/2021 22:45, Akhil Goyal: > > > In struct rte_security_ipsec_sa_options, for every new option > > > added, there is an ABI breakage, to avoid, a reserved_opts > > > bitfield is added to for the remaining bits available in the > > > structure. > > > Now for every new sa option, these reserved_opts can be reduced > > > and new option can be added. > > > > How do you make sure this field is initialized to 0? > > > Struct rte_security_ipsec_xform Is part of rte_security_capability as well > As a configuration structure in session create. > User, should ensure that if a device support that option(in capability), then > only these options will take into effect or else it will be don't care for the PMD. > The initial values of capabilities are set by PMD statically based on the features > that it support. > So if someone sets a bit in reserved_opts, it will work only if PMD support it > And sets the corresponding field in capabilities. > But yes, if a new field is added in future, and user sets the reserved_opts by mistake > And the PMD supports that feature as well, then that feature will be enabled. > This may or may not create issue depending on the feature which is enabled. > > Should I add a note in the comments to clarify that reserved_opts should be set as 0 > And future releases may change this without notice(But reserved in itself suggest that)? > Adding an explicit check in session_create does not make sense to me. > What do you suggest? > > Regards, > Akhil > The problem is if user creates an on stack variable and sets the unreserved fields to good values but other parts are garbage. This passes API/ABI unless you strictly enforce that all reserved fields are zero.