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, 05 May 2008 11:42:41 +1000
From:	John Williams <john.williams@...alogix.com>
To:	monstr@...nam.cz
Cc:	linux-kernel@...r.kernel.org, arnd@...db.de,
	linux-arch@...r.kernel.org, stephen.neuendorffer@...inx.com,
	John.Linn@...inx.com, matthew@....cx, will.newton@...il.com,
	drepper@...hat.com, microblaze-uclinux@...e.uq.edu.au,
	grant.likely@...retlab.ca, Michal Simek <monstr@...str.eu>
Subject: Re: [PATCH 01/56] microblaze_v2: Kconfig patches

Hi Michal,

On Sun, 2008-05-04 at 13:40 +0200, monstr@...nam.cz wrote:

> +config EARLY_PRINTK_UARTLITE_ADDRESS
> +	hex "Physical address where UART Lite for early printk is mapped"
> +	depends on EARLY_PRINTK
> +	default "0x40100000"
> +	help
> +	  Please enter physical address where your uart lite is mapped.

I think this should default to 0x00000000, then in the early_printk code
we can test for zero baseaddress and attempt some sensible fallback in
that case (even to disable).  
> +
> +config HEART_BEAT
> +	bool "Heart beat function for kernel"
> +	help
> +	  This option turns on/off heart beat kernel functionality on selected
> +	  GPIO address.
> +
> +config HEART_BEAT_ADDRESS
> +	hex "Physical address for heart beat LED"
> +	depends on HEART_BEAT
> +	default "0x40600000"
> +	help
> +	  Please enter physical address GPIO LED.

Again, default address should be zero which is checked in the code (zero
can disable).  Prevent accesses to random memory locations in case of
poorly configured kernel.


> +config HACK
> +	bool "Increase performance"
> +	default y

As suggested by Grant, this sohuld be

1. renamed and described as something sensible

SELF_MODIFYING_CODE_HACK

2. Made condition on CONFIG_EXPERIMENTAL at very least.

> +config OPT_LIB_FUNCTION
> +	bool "Optimalized lib function"
> +	default y
> +	help
> +	  Allows turn on optimalized library function (memcpy and memmove).
> +	  They are optimized by using unsigned alignment. This will work

"Unsigned alignment"??

Do you mean word-aligned?

> +	  fine if both source and destination are aligned on the same
> +	  boundary. However, if they are aligned on different boundaries
> +	  shifts will be necessary. This might result in bad performance
> +	  on MicroBlaze systems without a barrel shifter.
> +
> +# This is still a bit broken - disabling for now JW 20070504
> +config ALLOW_EDIT_AUTO
> +	bool "Permit Display/edit of Kconfig.auto platform settings"
> +	default n
> +	help
> +	  Allows the editing of auto-generated platform settings from
> +	  the Kconfig.auto file. Obviously this does not change the
> +	  underlying hardware, so be very careful if you go editing
> +	  these settings.
> +
> +	  Also, if you enable this, and edit various Kconfig.auto
> +	  settings, YOUR CHANGES WILL BE LOST if you then disable it
> +	  again. You have been warned!
> +
> +	  If unsure, say no.
> +
> +# Ok, the platform is chosen. Source the kconfig.auto to get all of the
> +# system settings.

Should be just "get all of the CPU settings", since we use OF to get the
device tree.

> diff --git a/arch/microblaze/platform/generic/Kconfig.auto b/arch/microblaze/platform/generic/Kconfig.auto
> new file mode 100644
> index 0000000..5dc8c15
> --- /dev/null
> +++ b/arch/microblaze/platform/generic/Kconfig.auto

> +config XILINX_ERAM_SIZE
> +	hex "Memory size of XILINX_RAM"
> +	depends on XILINX_UNCACHED_SHADOW
> +	default 0x02000000

Why does this depend on UNCACHED_SHADOW?

Regards,

John



--
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