From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) by sourceware.org (Postfix) with ESMTPS id 400AA385840E for ; Tue, 8 Nov 2022 21:07:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 400AA385840E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ej1-x62c.google.com with SMTP id k2so41854193ejr.2 for ; Tue, 08 Nov 2022 13:07:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vHxDgc9hUBIZzRk7YA+uwXYRuLnlv4eidkf78/vt/6o=; b=p78ulJ+fBmBeB1qUjN5kVDbjzibjeudH6Ncf7Y+Nz+0uTLzFxBdU4Lv59jcqnNIc24 cfdTmJnV8gMlVbp5AvQfNtswxp2IEeQL0Rjhb6t6k6tdW38BJUvC4ZcJbMhl5zIvVchU rplO8/ObXHiusqHPQTobREC/WXaHbjc2+bErIL57YsoUTJ3NBHMmvX1S65nBPsAcp6jU FIscoIaCyfj9c3tVMT8YQd+oamHIv8eR7+Ia7hc1zQH8oHzrA8q8PNT4RkfBNWZCJkws o86zGAS3DRfZlm7lO5spGpXLKvyyac90ICKM0L5V8HNQR/D9ThJBhX5U/mFMVKwuO4r2 Pc0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vHxDgc9hUBIZzRk7YA+uwXYRuLnlv4eidkf78/vt/6o=; b=QYWZzXG+Dl4P9k7NVbaSV5zJWEluanGUIflAzYg6j71gvOwiO7cW62X1QYvMYzyCYz eov+splFBITYtxDHTbDhOcOvPVz+pTwM43wA5LbcHDAn3A4DJ9cqPV7GgdqKxSkUtO2E bbCUat9OaF3t/MfIb+Qece4HXsJHbed0oTUxd0XsF+CkMDoj0daYUrXGMr3TtsGcR6fK w7TDZl+yY5dsWxMcUwI3D6B4RpaEgd+7/mhHjdN5NV5plW09wHPjObS24hc+PMbD0CqX f+JOaSJbIIbXLdxxhG1H+S1QzvHzICs5EIM4L73tEvo6+rEhWT7pn8jaAUn++Y9oUOa7 lySQ== X-Gm-Message-State: ACrzQf23UT0WDivk8129N0NGx5vYhh9uKrgSzW0rN5LVot1FCw28Anhz Vq/ANOeIKRiTJYA8CPGAAmWiauKPDwYEVuIfk7k= X-Google-Smtp-Source: AMsMyM6kTgOyiaS43S4IUDUCwI/aS2yjDZap/nb4/kRGLFAzFT1/uMTSrtYn3gRsYFiRcazZGXRZhgsnculAfsWn2DQ= X-Received: by 2002:a17:907:1dc8:b0:7ad:b792:2fec with SMTP id og8-20020a1709071dc800b007adb7922fecmr50336150ejc.732.1667941624923; Tue, 08 Nov 2022 13:07:04 -0800 (PST) MIME-Version: 1.0 References: <20221104205547.3728827-1-hjl.tools@gmail.com> <781ed098-079c-212e-7e46-a375c27f5486@suse.com> <73b15165-8615-282a-560f-30049b1963a1@suse.com> <6c7794ee-49fa-68d0-e659-435512da64fe@suse.com> In-Reply-To: <6c7794ee-49fa-68d0-e659-435512da64fe@suse.com> From: "H.J. Lu" Date: Tue, 8 Nov 2022 13:06:24 -0800 Message-ID: Subject: Re: [PATCH] i386: Check invalid (%dx) usage To: Jan Beulich Cc: binutils@sourceware.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3017.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, Nov 7, 2022 at 11:34 PM Jan Beulich wrote: > > On 07.11.2022 20:58, H.J. Lu wrote: > > On Mon, Nov 7, 2022 at 3:44 AM Jan Beulich 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. > > Well, perhaps both incl and incw then? Sure. > >> 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. > > We use current_templates in similar ways in quite a number of places, > when match_templates() hasn't run yet. Since the first template isn't the selected one, your check allows the invalid opcodes. > >> 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. > > Interesting view. I think with just this code added you'd still see > mis-assembly; you merely wouldn't see ... True since it uses the invalid template. > >> operand: The lack thereof was responsible for SEGV when (%dx) was > >> (wrongly) used with certain insns. > > ... SEGV anymore. > > Jan -- H.J.