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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 10 Aug 2009 09:29:06 +0200
From:	Michal Simek <michal.simek@...alogix.com>
To:	microblaze-uclinux@...e.uq.edu.au
CC:	John Linn <John.Linn@...inx.com>,
	David DeBonis <david.debonis@...inx.com>,
	Linux Kernel list <linux-kernel@...r.kernel.org>
Subject: Re: [microblaze-uclinux] Rethinking MicroBlaze commandline precedence

Hi John,

John Williams wrote:
> Hi,
> 
> Currently, MicroBlaze commandline handling in order of lowest to
> highest priority, looks like this:
> 
> 1. pointer in r5 from bootloader
> 2. CONFIG_CMDLINE=...
> 3. "chosen" section in DTS/DT
> 4. CONFIG_CMDLINE=... && CONFIG_CMDLINE_FORCE
> 
> I'm wondering if a cmdline in r5 should override the DTS.  My thinking
> is based on two observations:
> 
> (a) not everyone will use a bootloader like u-boot that can manipulate
> DTBs easily before kernel boot
> (b) a custom cmdline string in r5 allows the latest possible binding
> (runtime), where as the DTB is typically created at compile time.
> 
> So, how about this order instead:
> 
> 1. CONFIG_CMDLINE=...
> 2. "chosen" section in DTS/DT
> 3. pointer in r5 from bootloader
> 4. CONFIG_CMDLINE=... and CONFIG_CMDLINE_FORCE
> 
> Then, apart from CMDLINE_FORCE, the precedence goes from earliest
> binding (kernel build) to latest (runtime via bootloader/r5).
> 
> Thoughts?

I see there one big problem which can easily arise. Kernel expect that r5 points to
NULL string and DTS/DTB and CMDLINE will contain correct string. Kernel just copy it and use
it. There will be undefined behavior for more cases than for current handling. It will be
less error prune.

Ad observation a)

My expectation is that users will use s.....I.... format (I don't like that name - What about
renaming it?) with dtb - they setup commandline at once and they don't change it.

Ad observation b) - for final product they will use only one command line. For testing you can setup
kernel to use only r5.

I understand that you are trying to pass to kernel for example MTD map which could be possible but
IMHO better to do this in script which one with sed erase/comment/setup command line in DTS before
compilation.

Regards,
Michal


> 
> John

-- 
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ