linux-kernel - Re: 2.6.28-rc1: NVRAM being corrupted on ppc64 preventing boot (bisected)

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:	Fri, 31 Oct 2008 22:10:55 +1100
From:	Paul Mackerras <paulus@...ba.org>
To:	Mel Gorman <mel@....ul.ie>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	benh@...nel.crashing.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linuxppc-dev@...abs.org
Subject: Re: 2.6.28-rc1: NVRAM being corrupted on ppc64 preventing boot (bisected)

Mel Gorman writes:

> Yaboot in my case and I've heard it affected a DVD installation. I don't
> know for sure if it affects netboot but as I think it's something the
> kernel is doing, it probably doesn't matter how it gets loaded?

What changed in that commit was the contents of a couple of structures
that the firmware looks at to see what the kernel wants from
firmware.  Specifically the change was to say that the kernel (or
really the zImage wrapper) would like the firmware to be based at the
32MB point (which is what AIX uses) rather than 12MB (which was the
default on older machines).

So, as I understand it, it's not anything the kernel is actively
doing, it's how the firmware is reacting to what the kernel says it
wants.  And since we are requesting the same value as AIX (as far as I
know) I'm really surprised it caused problems.

We can revert that commit, but I still need to solve the problem that
the distros are facing, namely that their installer kernel + initramfs
images are now bigger than 12MB and can't be loaded if the firmware is
based at 12MB.  That's why I really want to understand the problem in
more detail.

> It's been pointed out that it can be "fixed" by upgrading the firmware but
> surely we can avoid breaking the machine in the first place?

Have you upgraded the firmware on the machine you saw this problem on?
If not, would you be willing to run some tests for me?

Paul.
--
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/