linux-kernel - RE: memcpy_fromio in dmi

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]

Date:	Wed, 24 Apr 2013 21:22:08 +0200
From:	Jean Delvare <jdelvare@...e.de>
To:	"Luck, Tony" <tony.luck@...el.com>
Cc:	DuanZhenzhong <zhenzhong.duan@...cle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	"Yu, Fenghua" <fenghua.yu@...el.com>
Subject: RE: memcpy_fromio in dmi_scan.c

Hi Tony,

Thanks for stepping in.

Le Tuesday 23 April 2013 à 22:00 +0000, Luck, Tony a écrit :
> > I don't have much knowledge about IA64 either. All I see is that while
> > x86 implements memcpy_fromio() with memcpy [1], ia64 implements it with
> > readb [2]. There must be a reason for that, and I can only suppose that
> > memcpy on __iomem pointers doesn't work on IA64. If memcpy doesn't work
> > then I can't see memcmp working.
> 
> On most platforms readb() just ends up doing a regular dereference of the
> address ... so I'd expect that memcmp would work just fine.  The exception
> is the old SGI sn2 which end up calling ___sn_readb() ... which does something
> weird with sn_dma_flush() after doing the dereference of *addr.  I don't
> really understand what is going on here - but I assume that it is for real
> PCI iomapped memory, as opposed to random bits of BIOS reserved memory
> that we used ioremap() to get a virtual handle on.

Ah, OK. I tested on a HP RX8640 server and to my surprised it worked
fine. But now your explanation tells me why. Now I also tested on a
Supermicro I8QBH, and it worked. But on a SGI SN2 I get the following in
dmesg (with kernel 3.0.70, which has the suspicious code changes):

DMI not present or invalid.

> Not sure how to test ... what would I run to exercise this code?

It is executed at boot time, if it works you get something like:

SMBIOS 2.7 present.

or:

DMI present.

in dmesg. If not, you get instead:

DMI not present or invalid.

That being said, "my" SN2 machine was previously running kernel 3.0.34
which has the old dmi_scan code and it also said "DMI not present or
invalid." Plus dmidecode fails on this machine with:

/sys/firmware/efi/systab: SMBIOS entry point missing

So it might as well be that DMI support on SN2 was already broken.
Please let me know your findings on other SN2 machines.

Anyway, either memcpy_fromio is needed and the code should be fixed, or
it isn't and the code should be simplified. The current state makes
little sense.

What is strange is that the call to memcpy_fromio was added a long time
ago, long before dmi_scan was enabled on ia64.

-- 
Jean Delvare
Suse L3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/