RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1795224 - [RFE] nftables: Support for sets with concatenated ranges
Summary: [RFE] nftables: Support for sets with concatenated ranges
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: nftables
Version: 8.1
Hardware: All
OS: Linux
high
medium
Target Milestone: rc
: 8.1
Assignee: Phil Sutter
QA Contact: Tomas Dolezal
URL:
Whiteboard:
Depends On: 1593711
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-01-27 13:28 UTC by Stefano Brivio
Modified: 2022-05-02 03:08 UTC (History)
5 users (show)

Fixed In Version: nftables-0.9.3-11.el8
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-28 16:42:15 UTC
Type: Feature Request
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-33627 0 None None None 2022-05-02 03:08:05 UTC
Red Hat Product Errata RHEA-2020:1774 0 None None None 2020-04-28 16:42:33 UTC

Description Stefano Brivio 2020-01-27 13:28:50 UTC
Support for nftables sets with concatenated ranges needs three patches
in nft, submitted upstream, not merged yet:

  http://patchwork.ozlabs.org/patch/1225480/
  http://patchwork.ozlabs.org/patch/1225481/
  http://patchwork.ozlabs.org/patch/1225482/

the kernel counterpart is covered by bz1593711 -- kernel patches are
upstream now.

I'm requesting exception status for this ticket as bz1593711, that
originally covered the userspace implementation, and I later used to
track the kernel feature (as it represented the bulk of this work), is
in the RPL for 8.2.

Comment 3 Phil Sutter 2020-02-10 14:21:35 UTC
Upstream commits to backport:

commit 9b94127950f9848bc5a1505ae65ca3045ff68a16
Author: Stefano Brivio <sbrivio>
Date:   Thu Jan 30 01:16:55 2020 +0100

    include: resync nf_tables.h cache copy
    
    Get this header in sync with nf-next as of merge commit
    b3a608222336 (5.6-rc1-ish).
    
    Signed-off-by: Stefano Brivio <sbrivio>
    Signed-off-by: Pablo Neira Ayuso <pablo>

commit 6156ba34018dddd59cb6737cfd5a69a0cbc5eaa4
Author: Stefano Brivio <sbrivio>
Date:   Thu Jan 30 01:16:56 2020 +0100

    src: Add support for NFTNL_SET_DESC_CONCAT
    
    To support arbitrary range concatenations, the kernel needs to know
    how long each field in the concatenation is. The new libnftnl
    NFTNL_SET_DESC_CONCAT set attribute describes this as an array of
    lengths, in bytes, of concatenated fields.
    
    While evaluating concatenated expressions, export the datatype size
    into the new field_len array, and hand the data over via libnftnl.
    
    Similarly, when data is passed back from libnftnl, parse it into
    the set description.
    
    When set data is cloned, we now need to copy the additional fields
    in set_clone(), too.
    
    This change depends on the libnftnl patch with title:
      set: Add support for NFTA_SET_DESC_CONCAT attributes
    
    v4: No changes
    v3: Rework to use set description data instead of a stand-alone
        attribute
    v2: No changes
    
    Signed-off-by: Stefano Brivio <sbrivio>
    Signed-off-by: Pablo Neira Ayuso <pablo>

commit 8ac2f3b2fca38b6533043b0678730c10ba4dc5ef
Author: Stefano Brivio <sbrivio>
Date:   Thu Jan 30 01:16:57 2020 +0100

    src: Add support for concatenated set ranges
    
    After exporting field lengths via NFTNL_SET_DESC_CONCAT attributes,
    we now need to adjust parsing of user input and generation of
    netlink key data to complete support for concatenation of set
    ranges.
    
    Instead of using separate elements for start and end of a range,
    denoting the end element by the NFT_SET_ELEM_INTERVAL_END flag,
    as it's currently done for ranges without concatenation, we'll use
    the new attribute NFTNL_SET_ELEM_KEY_END as suggested by Pablo. It
    behaves in the same way as NFTNL_SET_ELEM_KEY, but it indicates
    that the included key represents the upper bound of a range.
    
    For example, "packets with an IPv4 address between 192.0.2.0 and
    192.0.2.42, with destination port between 22 and 25", needs to be
    expressed as a single element with two keys:
    
      NFTA_SET_ELEM_KEY:            192.0.2.0 . 22
      NFTA_SET_ELEM_KEY_END:        192.0.2.42 . 25
    
    To achieve this, we need to:
    
    - adjust the lexer rules to allow multiton expressions as elements
      of a concatenation. As wildcards are not allowed (semantics would
      be ambiguous), exclude wildcards expressions from the set of
      possible multiton expressions, and allow them directly where
      needed. Concatenations now admit prefixes and ranges
    
    - generate, for each element in a range concatenation, a second key
      attribute, that includes the upper bound for the range
    
    - also expand prefixes and non-ranged values in the concatenation
      to ranges: given a set with interval and concatenation support,
      the kernel has no way to tell which elements are ranged, so they
      all need to be. For example, 192.0.2.0 . 192.0.2.9 : 1024 is
      sent as:
    
      NFTA_SET_ELEM_KEY:            192.0.2.0 . 1024
      NFTA_SET_ELEM_KEY_END:        192.0.2.9 . 1024
    
    - aggregate ranges when elements received by the kernel represent
      concatenated ranges, see concat_range_aggregate()
    
    - perform a few minor adjustments where interval expressions
      are already handled: we have intervals in these sets, but
      the set specification isn't just an interval, so we can't
      just aggregate and deaggregate interval ranges linearly
    
    v4: No changes
    v3:
     - rework to use a separate key for closing element of range instead of
       a separate element with EXPR_F_INTERVAL_END set (Pablo Neira Ayuso)
    v2:
     - reworked netlink_gen_concat_data(), moved loop body to a new function,
       netlink_gen_concat_data_expr() (Phil Sutter)
     - dropped repeated pattern in bison file, replaced by a new helper,
       compound_expr_alloc_or_add() (Phil Sutter)
     - added set_is_nonconcat_range() helper (Phil Sutter)
     - in expr_evaluate_set(), we need to set NFT_SET_SUBKEY also on empty
       sets where the set in the context already has the flag
     - dropped additional 'end' parameter from netlink_gen_data(),
       temporarily set EXPR_F_INTERVAL_END on expressions and use that from
       netlink_gen_concat_data() to figure out we need to add the 'end'
       element (Phil Sutter)
     - replace range_mask_len() by a simplified version, as we don't need
       to actually store the composing masks of a range (Phil Sutter)
    
    Signed-off-by: Stefano Brivio <sbrivio>
    Signed-off-by: Pablo Neira Ayuso <pablo>

Comment 11 errata-xmlrpc 2020-04-28 16:42:15 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2020:1774


Note You need to log in before you can comment on or make changes to this bug.