linux-kernel - Re: [patch 29/29] initrd: Fix virtual/physical mix-up in overwrite test

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:	Sat, 26 Jul 2008 01:27:31 +0900 (JST)
From:	Atsushi Nemoto <anemo@....ocn.ne.jp>
To:	geert@...ux-m68k.org
Cc:	ralf@...ux-mips.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, linux-m68k@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-mips@...ux-mips.org,
	linux-arch@...r.kernel.org
Subject: Re: [patch 29/29] initrd: Fix virtual/physical mix-up in overwrite
 test

On Thu, 24 Jul 2008 20:49:27 +0200 (CEST), Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> > Because an argument of mips virt_to_phys() is an pointer and
> > initrd_start is unsigned long.  It seems most (all?) arch's
> > virt_to_phys() casts its argument to unsigned long internally.  Should
> > mips follow?
> 
> Alternatively, as initrd_start is really a virtual kernel address,
> perhaps it should be changed from unsigned long to void * instead?
> 
> It's cast to `void *' in several place. arch/xtensa/kernel/setup.c even
> has `extern void *initrd_start' to fool around this?

I agree it would make code cleaner, but the conversion might be
somewhat hard.

If we converted initrd_start (and initrd_end) to void *, we should
also convert INITRD_START, free_initrd_mem(), some other arch specific
local/global variables and printk format strings.  Also code like
"initrd_start & PAGE_MASK" should be changed too...

Is it worth to do?

---
Atsushi Nemoto
--
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/