Re: [U-Boot] Password protection of U-Boot command line
2012/2/11 Graeme Russ graeme.r...@gmail.com: Hi Mike, On 02/11/2012 07:37 AM, Mike Frysinger wrote: waving your hands around and saying doing XXX is more secure and therefore we should do it is theater. i'm not against passwords or ASLR or anything else Agreed - I've already said as much in the ASLR thread in u-boot, but like Wolfgang said, let's see the realistic plan. Well I might get back to this later I do a lot of work with Programmable Logic Controllers (PLCs) and Remote Telemetry Units (RTUs). One example of what the bootloader is used for is low-level configuration of the analogue input out output channels (calibration). This is done by entering a command in the bootloader command line and applying a known calibrated input (if calibrating an input channel) or connecting to a calibrated measurement instrument (if calibrating an output). This is not something that an end-user should be doing (and can be very dangerous if the calibration is modified). These inputs and outputs may be connected to critical equipment, and if something goes wrong, the device manufacture needs a level of certainty that these settings have not been changed. This is only one example - There are many other reasons that the end user should be 'kept out' of the bootloader. Physical access (JTAG) can be detected by 'warranty void if removed' stickers, so I would not be so concerned in this senario There has also been a recent bout of security breaches as a result of hard-coded passwords in device firmware, so being able to set the password is a must I think some form of 'access level' might be useful one day - e.g. the end-user can set a password to provide access to setting IP address while the manufacturer has a password for calibration and MAC address These are all some basic random thoughts I have, but I think they illustrate that as the bootloader expands in functionality, the need to provide a measure of security also increases... Graeme, if you want to keep people outisde the bootloader in a reasonably safe way and are developing your own hardware an option is to put the password in e.g. an eeprom and do a compare in u-boot. Of course a persistent hacker could retrieve the password but a casual user will not be able to enter. Having the password in eeprom makes that it is not disclosed with the code, it can be changed etc. Just make sure users do not have easy (sw) access to the device the password resides in, so e.g.disable access one way or another. One other way to prevent accidental access would be a jumper. If present no access to u-boot possible at all, if not present access is possible. And some stuff on it to view if it is tampered with. (if the jumper raises or lowers a gpio device on an i2c chip this can be easily detected in a u-boot script and depending on that action could be taken). My two cents. Frans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] usb/ehci: Add USB support for the MX6Q
On Sat, Feb 11, 2012 at 5:12 AM, Marek Vasut marek.va...@gmail.com wrote: btw Fabio, do we support mx6q USB host in mainline Linux ? Not yet, Marek. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Password protection of U-Boot command line
Dear Graeme, In message 4f35ebbf.3050...@gmail.com you wrote: I do a lot of work with Programmable Logic Controllers (PLCs) and Remote Telemetry Units (RTUs). One example of what the bootloader is used for is low-level configuration of the analogue input out output channels (calibration). This is done by entering a command in the bootloader command line and applying a known calibrated input (if calibrating an input channel) or connecting to a calibrated measurement instrument (if calibrating an output). This is not something that an end-user should be doing (and can be very dangerous if the calibration is modified). These inputs and outputs may be connected to critical equipment, and if something goes wrong, the device manufacture needs a level of certainty that these settings have not been changed. This is only one example - There are many other reasons that the end user should be 'kept out' of the bootloader. This implies the logic that these actions _have_ to be done in the boot loader, so you need to add security to it. I doubt if this assumption is correct. I think the calibration couldbe done as well (and in a much beter secured environment) when running an OS. There has also been a recent bout of security breaches as a result of hard-coded passwords in device firmware, so being able to set the password is a must The lower level access you provide to a system, the higher the risk that it can be broken in, and that break-ins will be of a more critical nature. I think some form of 'access level' might be useful one day - e.g. the end-user can set a password to provide access to setting IP address while the manufacturer has a password for calibration and MAC address Do not do this in the boot loader. It is not the environment for such things. When it comes to security, you are automatically pulling in things like encryption technologies, key management, etc. We do not want to pull this into a bootloader - it would just be a poor mans surrogate for a real OS. Instead, do the logical step and use a proper OS that provides all these things for free, in a well-tested and protected environment. These are all some basic random thoughts I have, but I think they illustrate that as the bootloader expands in functionality, the need to provide a measure of security also increases... I disagree. There are a large number of things that simply make no sense in boot loader context. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de What is tolerance? -- it is the consequence of humanity. We are all formed of frailty and error; let us pardon reciprocally each other's folly -- that is the first law of nature. - Voltaire ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Password protection of U-Boot command line
Dear Frans, In message cacw_htyv179qwbquiuv_qqbe_bly9b_h-qpzsbcjkpio9-2...@mail.gmail.com you wrote: Graeme, if you want to keep people outisde the bootloader in a reasonably safe way and are developing your own hardware an option is to put the password in e.g. an eeprom and do a compare in u-boot. Of course a persistent hacker could retrieve the password but a casual user will not be able to enter. For a casual user the existing CONFIG_AUTOBOOT_KEYED feature is usually sufficient. A persistent hacker will not be kept out in either of these ways if he has access to the U-Boot command line. If needed, he will install or otherwise run code that skips these steps. Having the password in eeprom makes that it is not disclosed with the code, it can be changed etc. Just make sure users do not have easy (sw) access to the device the password resides in, so e.g.disable access one way or another. You will still publish the code that implements these restrrictions, so guess how difficult it is to work around it? One other way to prevent accidental access would be a jumper. If present no access to u-boot possible at all, if not present access is possible. And some stuff on it to view if it is tampered with. (if the jumper raises or lowers a gpio device on an i2c chip this can be easily detected in a u-boot script and depending on that action could be taken). None of this is actually adding any kid of security or protection to a device. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Horses just naturally have mohawk haircuts. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [i2c] Pull request
Dear Heiko Schocher, In message 4f1fa08a.7040...@denx.de you wrote: Hello Wolfgang, The following changes since commit 137703b811502dfea364650fb3e17f20b4c21333: overo: add SPL support (2012-01-16 08:40:13 +0100) are available in the git repository at: git://git.denx.de/u-boot-i2c.git master Patil, Rachna (3): ARM: I2C: I2C Multi byte address support ARM: AM33XX: Add AM33XX I2C driver support ARM: AM33XX: Add i2c support arch/arm/cpu/armv7/am33xx/clock.c |5 + arch/arm/include/asm/arch-am33xx/common_def.h |1 + arch/arm/include/asm/arch-am33xx/cpu.h|3 +- arch/arm/include/asm/arch-am33xx/i2c.h| 81 + board/ti/am335x/evm.c |7 + board/ti/am335x/mux.c | 13 + drivers/i2c/omap24xx_i2c.c| 475 - drivers/i2c/omap24xx_i2c.h|2 + include/configs/am335x_evm.h |9 + 9 files changed, 421 insertions(+), 175 deletions(-) create mode 100644 arch/arm/include/asm/arch-am33xx/i2c.h Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: nand flash
Dear Scott Wood, In message 20120126221209.ga18...@schlenkerla.am.freescale.net you wrote: These patches were posted before the close of the merge window. The following changes since commit 137703b811502dfea364650fb3e17f20b4c21333: overo: add SPL support (2012-01-16 08:40:13 +0100) are available in the git repository at: git://git.denx.de/u-boot-nand-flash.git master Christian Hitz (7): nand: Merge BCH code from Linux nand driver nand: Add more NAND types from Linux nand driver nand: cleanup whitespace nand: Merge changes from Linux nand driver nand: Merge changes to BBT from Linux nand driver nand: Sanitize ONFI strings. nand: make 1-bit software ECC configurable Scott Wood (4): NAND: Remove additional (CONFIG_SYS)_NAND_MAX_CHIPS nand_spl: store ecc data on the stack nand: Introduce CONFIG_SYS_NAND_SELF_INIT nand/fsl_elbc: Convert to self-init Shengzhou Liu (1): mtd/nand: Add ONFI support for FSL NAND controller Stefano Babic (1): nand_spl_simple: store ecc data on the stack Vladimir Zapolskiy (1): NAND: remove NAND_MAX_CHIPS definitions doc/README.nand| 62 ++ drivers/mtd/nand/Makefile |3 +- drivers/mtd/nand/fsl_elbc_nand.c | 60 ++- drivers/mtd/nand/nand.c| 96 ++- drivers/mtd/nand/nand_base.c | 677 +++-- drivers/mtd/nand/nand_bbt.c| 427 --- drivers/mtd/nand/nand_bch.c| 236 ++ drivers/mtd/nand/nand_ids.c| 35 + drivers/mtd/nand/nand_spl_simple.c | 42 +- include/configs/P1_P2_RDB.h|3 +- include/configs/PMC440.h |2 - include/configs/SIMPC8313.h|3 +- include/configs/VCMA9.h|1 - include/configs/acadia.h |2 - include/configs/am3517_crane.h |4 - include/configs/am3517_evm.h |4 - include/configs/aria.h |4 - include/configs/at91sam9m10g45ek.h |1 - include/configs/bamboo.h |2 - include/configs/bf526-ezbrd.h |1 - include/configs/bf527-ad7160-eval.h|1 - include/configs/bf527-ezkit.h |1 - include/configs/bf548-ezkit.h |1 - include/configs/cam_enc_4xx.h |4 - include/configs/canyonlands.h |2 - include/configs/cm-bf527.h |1 - include/configs/cpu9260.h |1 - include/configs/da830evm.h |1 - include/configs/da850evm.h |1 - include/configs/davinci_dm355leopard.h |1 - include/configs/devkit8000.h |5 - include/configs/ea20.h |1 - include/configs/eb_cpux9k2.h |1 - include/configs/enbw_cmc.h |1 - include/configs/hawkboard.h|6 +- include/configs/kilauea.h |2 - include/configs/km/km_arm.h|1 - include/configs/m28evk.h |1 - include/configs/mecp5123.h |2 - include/configs/mpc5121ads.h |1 - include/configs/mv-common.h|1 - include/configs/omap3_beagle.h |4 - include/configs/omap3_evm.h|4 - include/configs/omap3_evm_quick_nand.h |4 - include/configs/pdm360ng.h |2 - include/configs/pm9261.h |1 - include/configs/pm9263.h |1 - include/configs/pm9g45.h |1 - include/configs/qi_lb60.h |5 - include/configs/sequoia.h |2 - include/configs/smdk2410.h |1 - include/configs/smdk6400.h |4 - include/configs/tam3517-common.h |5 - include/configs/tnetv107x_evm.h|1 - include/configs/tt01.h |1 - include/linux/bch.h| 79 ++ include/linux/mtd/bbm.h| 25 +- include/linux/mtd/nand.h | 374 + include/linux/mtd/nand_bch.h | 72 ++ include/linux/mtd/nand_ecc.h | 25 + include/linux/string.h |4 + include/nand.h | 16 + lib/Makefile |1 + lib/bch.c | 1358 lib/string.c | 39 + nand_spl/nand_boot.c | 42 +- 66 files changed, 3082 insertions(+), 690 deletions(-) create mode 100644 drivers/mtd/nand/nand_bch.c create mode 100644 include/linux/bch.h create mode 100644 include/linux/mtd/nand_bch.h create mode 100644 lib/bch.c Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone:
Re: [U-Boot] Please pull u-boot-cfi-flash
Dear Stefan Roese, In message 201202091100.25756...@denx.de you wrote: Hi Wolfgang, please pull the following patches: The following changes since commit 137703b811502dfea364650fb3e17f20b4c21333: overo: add SPL support (2012-01-16 08:40:13 +0100) are available in the git repository at: git://www.denx.de/git/u-boot-cfi-flash.git master for you to fetch changes up to 5e72ef08105086de578582d3c7375601c77550db: add STM29F400BB to table of supported legacy flashs (2012-02-09 09:45:53 = +0100) David Müller (ELSOFT AG) (1): add STM29F400BB to table of supported legacy flashs Jens Scharsig (BuS Elektronik) (1): * Fix: watchdog timed out, if flash blank (0xFF) blocks drivers/mtd/cfi_flash.c |3 +++ drivers/mtd/jedec_flash.c | 20 2 files changed, 23 insertions(+), 0 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The light at the end of the tunnel is usually a No Exit sign. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fw_env.h: fix comment
Dear Frans Meulenbroeks, In message 1325786950-2148-1-git-send-email-fransmeulenbro...@gmail.com you wrote: made description according to implementation (where the config file is the default). Signed-off-by: Frans Meulenbroeks fransmeulenbro...@gmail.com --- tools/env/fw_env.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de ADVISORY: There is an Extremely Small but Nonzero Chance That, Through a Process Know as Tunneling, This Product May Spontaneously Disappear from Its Present Location and Reappear at Any Random Place in the Universe, Including Your Neighbor's Domicile. The Manufacturer Will Not Be Responsible for Any Damages or Inconvenience That May Result. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MAKEALL: display SPL size if present
Dear Scott Wood,
In message 20120105231610.ga10...@schlenkerla.am.freescale.net you wrote:
This makes it easier to detect changes in the SPL portion,
as can currently be done for the main U-Boot image.
Signed-off-by: Scott Wood scottw...@freescale.com
---
MAKEALL |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/MAKEALL b/MAKEALL
index f735af6..395e982 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -508,6 +508,11 @@ build_target() {
${CROSS_COMPILE}size ${BUILD_DIR}/u-boot \
| tee -a ${LOG_DIR}/$target.MAKELOG
+
+ if [ -e ${BUILD_DIR}/spl/u-boot-spl ]; then
+ ${CROSS_COMPILE}size ${BUILD_DIR}/spl/u-boot-spl \
+ | tee -a ${LOG_DIR}/$target.MAKELOG
+ fi
Can we please combine this into a single call to size?
Thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
...computer hardware progress is so fast. No other technology since
civilization began has seen six orders of magnitude in performance-
price gain in 30 years. - Fred Brooks, Jr.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
