From: "Jose E. Marchesi" <jose.marchesi@oracle.com>
To: Yonghong Song <yonghong.song@linux.dev>
Cc: bpf@vger.kernel.org, david.faust@oracle.com,
cupertino.miranda@oracle.com
Subject: Re: Masks and overflow of signed immediates in BPF instructions
Date: Tue, 15 Aug 2023 19:01:22 +0200 [thread overview]
Message-ID: <87leec44v1.fsf@oracle.com> (raw)
In-Reply-To: <ab4264da-7c73-e7c5-334d-ed61c9fdd241@linux.dev> (Yonghong Song's message of "Tue, 15 Aug 2023 09:12:33 -0700")
> On 8/15/23 7:19 AM, Jose E. Marchesi wrote:
>> Hello.
>> The selftest progs/verifier_masking.c contains inline assembly code
>> like:
>> w1 = 0xffffffff;
>> The 32-bit immediate of that instruction is signed. Therefore, GAS
>> complains that the above instruction overflows its field:
>> /tmp/ccNOXFQy.s:46: Error: signed immediate out of range, shall
>> fit in 32 bits
>> The llvm assembler is likely relying on signed overflow for the
>> above to
>> work.
>
> Not really.
>
> def _ri_32 : ALU_RI<BPF_ALU, Opc, off,
> (outs GPR32:$dst),
> (ins GPR32:$src2, i32imm:$imm),
> "$dst "#OpcodeStr#" $imm",
> [(set GPR32:$dst, (OpNode GPR32:$src2,
> i32immSExt32:$imm))]>;
>
>
> If generating from source, the pattern [(set GPR32:$dst, (OpNode
> GPR32:$src2, i32immSExt32:$imm))] so value 0xffffffff is not SExt32
> and it won't match and eventually a LDimm_64 insn will be generated.
If by "generating from source" you mean compiling from C, then sure, I
wasn't implying clang was generating `r1 = 0xffffffff' for assigning
that positive value to a register.
> But for inline asm, we will have
> (outs GPR32:$dst)
> (ins GPR32:$src2, i32imm:$imm)
>
> and i32imm is defined as
> def i32imm : Operand<i32>;
> which is a unsigned 32bit value, so it is recognized properly
> and the insn is encoded properly.
We thought the imm32 operand in ALU instructions is signed, not
unsigned. Is it really unsigned??
>> Using negative numbers to denote masks is ugly and obfuscating (for
>> non-obvious cases like -1/0xffffffff) so I suggest we introduce a
>> pseudo-op so we can do:
>> w1 = %mask(0xffffffff)
>
> I changed above
> w1 = 0xffffffff;
> to
> w1 = %mask(0xffffffff)
> and hit the following compilation failure.
>
> progs/verifier_masking.c:54:9: error: invalid % escape in inline
> assembly string
> 53 | asm volatile (" \
> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 54 | w1 = %mask(0xffffffff); \
> | ^
> 1 error generated.
>
> Do you have documentation what is '%mask' thing?
It doesn't exist.
I am suggesting to add support for that pseudo-op to the BPF assemblers:
both GAS and the llvm BPF assembler.
>> allowing the assembler to do the right thing (TM) converting and
>> checking that the mask is valid and not relying on UB.
>> Thoughts?
>>
next prev parent reply other threads:[~2023-08-15 17:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-15 14:19 Masks and overflow of signed immediates in BPF instructions Jose E. Marchesi
2023-08-15 16:12 ` Yonghong Song
2023-08-15 17:01 ` Jose E. Marchesi [this message]
2023-08-15 17:28 ` Yonghong Song
2023-08-16 9:36 ` Jose E. Marchesi
2023-08-16 16:22 ` Yonghong Song
2023-08-17 8:01 ` Jose E. Marchesi
2023-08-17 16:23 ` Yonghong Song
2023-08-17 17:14 ` Yonghong Song
2023-08-17 17:37 ` Jose E. Marchesi
2023-08-17 17:44 ` Yonghong Song
2023-08-17 18:06 ` Jose E. Marchesi
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=87leec44v1.fsf@oracle.com \
--to=jose.marchesi@oracle.com \
--cc=bpf@vger.kernel.org \
--cc=cupertino.miranda@oracle.com \
--cc=david.faust@oracle.com \
--cc=yonghong.song@linux.dev \
/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.