linux-kernel - Re: [PATCH 3/4] parisc: Use absolute_pointer for memcmp on fixed memory location

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 for Android: free password hash cracker in your pocket

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

Message-ID: <2702f518-da2f-5bca-11d3-35f5cd4316e6@roeck-us.net>
Date:   Sun, 12 Sep 2021 13:28:32 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Helge Deller <deller@....de>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Richard Henderson <rth@...ddle.net>,
        Ivan Kokshaysky <ink@...assic.park.msu.ru>,
        Matt Turner <mattst88@...il.com>,
        "James E . J . Bottomley" <James.Bottomley@...senpartnership.com>,
        "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        alpha <linux-alpha@...r.kernel.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-parisc@...r.kernel.org, Netdev <netdev@...r.kernel.org>,
        Sparse Mailing-list <linux-sparse@...r.kernel.org>
Subject: Re: [PATCH 3/4] parisc: Use absolute_pointer for memcmp on fixed
 memory location

On 9/12/21 12:58 PM, Helge Deller wrote:
> * Linus Torvalds <torvalds@...ux-foundation.org>:
>> On Sun, Sep 12, 2021 at 9:02 AM Guenter Roeck <linux@...ck-us.net> wrote:
>>>
>>> -       running_on_qemu = (memcmp(&PAGE0->pad0, "SeaBIOS", 8) == 0);
>>> +       running_on_qemu = (memcmp(absolute_pointer(&PAGE0->pad0), "SeaBIOS", 8) == 0);
>>
>> This seems entirely the wrong thing to do, and makes no sense. That
>> "&PAGE0->pad0" is a perfectly valid pointer, and that's not where the
>> problem is.
>>
>> The problem is "PAGE0" itself:
>>
>>      #define PAGE0   ((struct zeropage *)__PAGE_OFFSET)
>>
>> which takes that absolute offset and creates a pointer out of it.
>>
>> IOW, _that_ is what should have the "absolute_pointer()" thing, and in
>> that context the name of that macro and its use actually makes sense.
>>
>> No?
>>
>> An alternative - and possibly cleaner - approach that doesn't need
>> absolute_pointer() at all might be to just do
>>
>>          extern struct zeropage PAGE0;
>>
>> and then make that PAGE0 be defined to __PAGE_OFFSET in the parisc
>> vmlinux.lds.S file.
>>
>> Then doing things like
>>
>>          running_on_qemu = !memcmp(&PAGE0.pad0, "SeaBIOS", 8);
>>
>> would JustWork(tm).
> 
> Yes, this second approach seems to work nicely, although the patch
> then gets slightly bigger.
> Below is a tested patch.
> I'll check it some further and apply it to the parisc tree then.
> 

There are several PAGE0-> references left in the code after applying your patch.

$ git grep "PAGE0->"
arch/parisc/kernel/firmware.c:  if (!PAGE0->mem_kbd.iodc_io)
arch/parisc/kernel/firmware.c:  real32_call(PAGE0->mem_kbd.iodc_io,
arch/parisc/kernel/firmware.c:              (unsigned long)PAGE0->mem_kbd.hpa, ENTRY_IO_CIN,
arch/parisc/kernel/firmware.c:              PAGE0->mem_kbd.spa, __pa(PAGE0->mem_kbd.dp.layers),
arch/parisc/kernel/smp.c:       WARN_ON(((unsigned long)(PAGE0->mem_pdc_hi) << 32
arch/parisc/kernel/smp.c:                       | PAGE0->mem_pdc) != pdce_proc);

After fixing those, I can build a parisc image and boot it in qemu (32 bit).

Guenter