linux-kernel - Re: [PATCH] bcb: Android bootloader control block driver

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: <CAMbhsRSy+cYRDjmYtMdHNUSK4y+vSoEHgKNCaLvvNVopnSvh-Q@mail.gmail.com>
Date:	Sat, 7 Jul 2012 17:25:31 -0700
From:	Colin Cross <ccross@...roid.com>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	NeilBrown <neilb@...e.de>, Andrew Boie <andrew.p.boie@...el.com>,
	arve@...roid.com, rebecca@...roid.com, devel@...verdev.osuosl.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] bcb: Android bootloader control block driver

On Sat, Jul 7, 2012 at 4:05 PM, Greg KH <gregkh@...uxfoundation.org> wrote:
> On Sat, Jul 07, 2012 at 03:39:09PM -0700, Colin Cross wrote:
>> On many (most?) ARM SoCs, the reboot flag is not stored on disk, or
>> anywhere else userspace can access.  It is stored in a power
>> management controller scratch register that survives resets, or a
>> register in an external I2C PMIC, or in internal SoC RAM (I've seen
>> all of these).  For your proposal, every SoC would need a custom API
>> to save the reboot flag somewhere.  For these devices, it clearly
>> makes more sense to use something like the REBOOT2 API, and if we have
>> to use it on some devices, it makes no sense to me to not use it on
>> other devices just because userspace could theoretically handle it.
>
> That's fine, but that is not what this patch did at all.

Yes it is, this patch is exactly what I was referring to in the last
sentence.  This patch implements the REBOOT2 API a device where there
is no available persistent storage inside the SoC and the disk must be
used instead.

> Propose a patch that handles writing to those types of registers and we
> will be glad to review it.

This isn't getting anywhere.  Let me lay out my logic why a driver
that saves reboot reason on disk is useful, and you can tell me where
you disagree.  I'll use specific examples where I can to try to be
less vague.

OMAP4 Panda boards require kernel support for reboot reason, it is
stored in internal RAM ("SAR" RAM) that is also used for
suspend/resume.

Some Tegra boards (Motorola Xoom) require kernel support for reboot
reason, it is stored in the PMIC registers over I2C.

A common API is needed for Panda, Xoom, and a variety of other boards
that use unique storage locations, and the existing REBOOT2 API seems
to me to be designed for this purpose.

Other boards (don't have a specific example here, perhaps Andrew can
provide one) need to store the reboot reason on disk.

Because the REBOOT2 API exists and is required on Panda and Xoom, it
should work on Andrew's board as well.

This patch is an attempt to make the REBOOT2 API work on Andrew's board.

Where do you disagree?
--
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/