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: <2E57EB624252DB47AFBC064A9AFBA980077EE18B@ORSMSX105.amr.corp.intel.com>
Date:	Fri, 29 Jun 2012 21:56:36 +0000
From:	"Boie, Andrew P" <andrew.p.boie@...el.com>
To:	NeilBrown <neilb@...e.de>
CC:	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"ccross@...roid.com" <ccross@...roid.com>,
	"arve@...roid.com" <arve@...roid.com>,
	"rebecca@...roid.com" <rebecca@...roid.com>,
	"devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] bcb: Android bootloader control block driver

> From: NeilBrown [mailto:neilb@...e.de]
> Sent: Friday, June 29, 2012 2:25 PM
> 
> On Fri, 29 Jun 2012 12:36:30 -0700 Andrew Boie <andrew.p.boie@...el.com>
> wrote:
> 
> > Android userspace tells the kernel that it wants to boot into recovery
> > or some other non-default OS environment by passing a string argument
> > to reboot(). It is left to the OEM to hook this up to their specific
> > bootloader.

> Maybe I'm missing something obvious, but why does this need to be
> implemented
> in the kernel?  Can't some user-space process just write to that partition
> using open/read/seek/write/close before calling 'reboot'.

Thanks for reviewing. The way Android is currently designed, all calls to reboot the system into an alternate target go into android_reboot() in libcutils which then make the reboot() system call with a string argument. How this is actually done on a particular board is not specified in the Android Open Source Project as far as I can see. The particular bootloader is not specified either, many different ones are being used in practice.

Not  every architecture is going to be using the Bootloader Control Block to handle these boots into alternate targets. For example, I worked on one Android-based device that didn't have a traditional bootloader at all and the reboot hook in the kernel was radically different. In this case the BCB ended up only being used by the recovery console to stash its command line arguments.

 If this were all done in userspace, then I think there would have to be separate code paths in libcutils for different board implementations of this policy. As of right now libcutils doesn't have any hardware-specific stuff in it and the mechanism to effect these policies is left to the kernel, libcutils works everywhere without modification.

Regards,
Andrew
--
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/