linux-kernel - Re: unable to mmap /dev/kmem

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: <61ec3ea90701200919kd6593bdl8dcd47824ed03f49@mail.gmail.com>
Date:	Sat, 20 Jan 2007 18:19:47 +0100
From:	"Franck Bui-Huu" <fbuihuu@...il.com>
To:	"Hugh Dickins" <hugh@...itas.com>
Cc:	"Nadia Derbey" <Nadia.Derbey@...l.net>, "Andi Kleen" <ak@...e.de>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: unable to mmap /dev/kmem

On 1/19/07, Hugh Dickins <hugh@...itas.com> wrote:
>
> Apology surely accepted, it's a confusing area (inevitably: in a driver
> for mem, the distinction between addresses and offsets become blurred).
>
> But please note, the worst of it was, that your patch comment gave no
> hint that you were knowingly changing its behaviour on the "main"
> architectures: it reads as if you were simply fixing it up on a
> few less popular architectures where an anomaly had been missed.
>

Because I was thinking that the expected behaviour was the one
implemented before 2.6.12. So I really thought to fix a bug, again
sorry for not having checked the history...

That said, it's really confusing to pass a virtual address as an
offset because:

    (a) mmap() has always worked with offset not addresses;

    (b) the kernel will treat this virtual address as an offset
        until kmem driver convert it back to a virtual
        address. And it seems that during this convertion the
        lowest bits of the virtual address will be lost...

Maybe read/write behaviours should be changed to use the offset as an
offset and not as a virtual address.

> > > I guess it's reassuring to know that not many are actually
> > > using mmap of /dev/kmem, so you're the first to notice: thanks.
> >
> > yes it doesn't seems to be used. In my case, I was just playing with
> > it when I submitted the patch but have no real usages.
>
> Have I got it right, that actually the problem you thought you were
> fixing does not even exist?

yes, see above.

>  __pa was already doing the right thing on
> all architectures, wasn't it?  So we can simply ask Linus to revert your
> patch?

yes we can if the desired behaviour is the one introduced by 2.6.12.

> I don't think your PFN_DOWN or virt_to_phys were improvements:
> though mem.c happens to live in drivers/char/, imagine it under mm/.
>

I don't get your point here. Do you mean that virt_to_phys() is only
meant for drivers ? If so, I would have said that virt_to_phys() is
prefered once boot memory init is finished...

		Franck
-
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/