linux-kernel - Re: [RESEND PATCH v1] MIPS: uasm: false warning on use of uasm_i

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200910093709.GA10310@alpha.franken.de>
Date:   Thu, 10 Sep 2020 11:37:09 +0200
From:   Thomas Bogendoerfer <tsbogend@...ha.franken.de>
To:     Jim Quinlan <james.quinlan@...adcom.com>
Cc:     linux-mips@...r.kernel.org, bcm-kernel-feedback-list@...adcom.com,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [RESEND PATCH v1] MIPS: uasm: false warning on use of
 uasm_i_lui()

On Tue, Sep 08, 2020 at 12:45:06PM -0400, Jim Quinlan wrote:
> Currently, the example uasm code
> 
> 	uasm_i_lui(p, tmp, 0xa000);
> 
> issues a warning at Linux boot when the code is "assembled".  This is
> because the "lui" instruction is defined by the macro "Ip_u1s2(_lui)" -- I
> believe it should be Ip_u1u2(_lui) -- and its definition is associated with
> the SIMM macro -- I believe it should be the UIMM macro.  The current code
> takes a 32bit number and checks that it can be converted to a 16bit signed
> immediate.  This check fails of course for an immediate such as 0x0000a000.

IMHO SIMM is correct as the upper 16bits will be sign extended on 64bit
CPUs.

Your example looks like to try to load a KSEG1 address, so just use 

uasm_i_lui(p, tmp, uasm_rel_hi(0xa0000000));

which even makes it clearer, what this is about.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]