public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "H.J. Lu" <hjl.tools@gmail.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: binutils@sourceware.org
Subject: Re: [PATCH] i386: Check invalid (%dx) usage
Date: Mon, 7 Nov 2022 11:58:38 -0800	[thread overview]
Message-ID: <CAMe9rOoBZsq2dh_-xdcu=0pfFA_X-N1v5kXKJP8+oE3MbrRMNg@mail.gmail.com> (raw)
In-Reply-To: <73b15165-8615-282a-560f-30049b1963a1@suse.com>

On Mon, Nov 7, 2022 at 3:44 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 07.11.2022 10:55, Jan Beulich via Binutils wrote:
> > On 04.11.2022 21:55, H.J. Lu via Binutils wrote:
> >> (%dx) isn't a valid memory address in any modes.  It is used as a special
> >> memory operand for input/output port address in AT&T syntax and should
> >> only be used with input/output instructions.  Update i386_att_operand to
> >> set i.input_output_operand to true for (%dx) and issue an error if (%dx)
> >> is used with non-input/output instructions.
> >
> > Hmm, this shouldn't require a new flag I would hope. We did properly reject
> > bad uses up to 2.31 ("operand type mismatch"). Whatever was broken there
> > would need correcting instead, imo. A possible candidate looks to be
> > 2fb5be8dac9d ("x86: drop {,reg16_}inoutportreg variables"), albeit perhaps
> > combined with later changes - in 2.33 behavior changed again.
>
> What about the change below, perhaps combined with your testsuite adjustments
> (albeit I'd like to point out that "incl" isn't the best choice, as %dx is

Since incl is misassembled, it is a good test.

> invalid with that anyway; "incw" would be better)? That way we'll uniformly
> get "`(%dx)' is not a valid base/index expression" for bad uses of (%dx),
> matching any other uses of wrong addressing forms.
>
> Jan
>
> x86: restrict use of (%dx)
>
> PR gas/29751
> The AT&T mode special case operand (%dx) is valid to use only with
> instructions nominally expecting %dx to specify an I/O port address.
> Prefix the respective checking with an opcode check. Keep that as
> simple as possible by recognizing that opcodes 0x64 and 0x66 (which

Since current_templates doesn't point to the matched instruction,
checking current_templates looks like abuse.  I don't think error
messages should be a concern here.

> wrongly also match the check) encode prefixes, which hence - even if
> used standalone - don't take any operands, so match_template() will
> fail there for other reasons.
>
> While there also complete the transformation from memory to register

I prefer to keep it ASIS since the lack of the transformation helped
catch this error.

> operand: The lack thereof was responsible for SEGV when (%dx) was
> (wrongly) used with certain insns.
>
> --- a/gas/config/tc-i386.c
> +++ b/gas/config/tc-i386.c
> @@ -11884,7 +11884,9 @@ i386_att_operand (char *operand_string)
>         }
>
>        /* Special case for (%dx) while doing input/output op.  */
> -      if (i.base_reg
> +      if ((current_templates->start->base_opcode | 0x8a) == 0xee
> +         && current_templates->start->opcode_modifier.opcodespace == SPACE_BASE
> +         && i.base_reg
>           && i.base_reg->reg_type.bitfield.instance == RegD
>           && i.base_reg->reg_type.bitfield.word
>           && i.index_reg == 0
> @@ -11893,6 +11895,8 @@ i386_att_operand (char *operand_string)
>           && !operand_type_check (i.types[this_operand], disp))
>         {
>           i.types[this_operand] = i.base_reg->reg_type;
> +         i.op[this_operand].regs = i.base_reg;
> +         i.reg_operands++;
>           return 1;
>         }
>
>
>


-- 
H.J.

  reply	other threads:[~2022-11-07 19:59 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-04 20:55 H.J. Lu
2022-11-07  9:55 ` Jan Beulich
2022-11-07 11:44   ` Jan Beulich
2022-11-07 19:58     ` H.J. Lu [this message]
2022-11-08  7:34       ` Jan Beulich
2022-11-08 21:06         ` H.J. Lu
2022-11-09  7:21           ` Jan Beulich
2022-11-09 20:24             ` H.J. Lu
2022-11-10  7:21               ` Jan Beulich
2022-11-10 17:22                 ` H.J. Lu
2022-11-11  7:55                   ` Jan Beulich

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='CAMe9rOoBZsq2dh_-xdcu=0pfFA_X-N1v5kXKJP8+oE3MbrRMNg@mail.gmail.com' \
    --to=hjl.tools@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=jbeulich@suse.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).