All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Florian Westphal <fw@strlen.de>, netfilter-devel@vger.kernel.org
Subject: Re: [RFC nf-next 2/4] netfilter: nf_tables: allow loads only when register is initialized
Date: Tue, 2 Jul 2024 00:16:42 +0200	[thread overview]
Message-ID: <20240701221642.GA11142@breakpoint.cc> (raw)
In-Reply-To: <ZoMSIF0jVEe1ro5T@calendula>

Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > +	next_register = DIV_ROUND_UP(len, NFT_REG32_SIZE) + reg;
> > +
> > +	/* Can't happen: nft_validate_register_load() should have failed */
> > +	if (WARN_ON_ONCE(next_register > NFT_REG32_NUM))
> > +		return -EINVAL;
> > +
> > +	/* find first register that did not see an earlier store. */
> > +	invalid_reg = find_next_zero_bit(ctx->reg_inited, NFT_REG32_NUM, reg);
> 
> Is this assuming that register allocation from userspace is done secuencially?

No, that would be a bug.

Each set bit represents a register, if the bit is 1, the register
saw a store.

The above is the load check: load is from register "reg", and we
check the first reg that did not see a store (is 0), starting from
reg.  The result (register with undefined content) needs to be larger
than next_register, which is the register coming after the current
access (can be NFT_REG32_NUM, in that case no furhter registers exist
and access is ok).

> > +	/* invalid register within the range that we're loading from? */
> > +	if (invalid_reg < next_register)
> > +		return -ENODATA;
> > +

This means that in range the relevant access range
[reg,next_reg) the is at least on register that did not see a store.


  reply	other threads:[~2024-07-01 22:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-27 13:53 [RFC nf-next 0/4] nf_tables: remove explicit register zeroing Florian Westphal
2024-06-27 13:53 ` [RFC nf-next 1/4] netfilter: nf_tables: pass context structure to nft_parse_register_load Florian Westphal
2024-06-27 13:53 ` [RFC nf-next 2/4] netfilter: nf_tables: allow loads only when register is initialized Florian Westphal
2024-07-01 20:31   ` Pablo Neira Ayuso
2024-07-01 22:16     ` Florian Westphal [this message]
2024-06-27 13:53 ` [RFC nf-next 3/4] netfilter: nf_tables: insert register zeroing instructions for dodgy chains Florian Westphal
2024-07-01 20:30   ` Pablo Neira Ayuso
2024-07-01 22:18     ` Florian Westphal
2024-07-01 22:32       ` Pablo Neira Ayuso
2024-06-27 13:53 ` [RFC nf-next 4/4] netfilter: nf_tables: don't initialize registers in nft_do_chain() Florian Westphal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240701221642.GA11142@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.