Re: [Ltib] Security fixes and merging changes upstream

[address@hidden]

On Sun, Oct 23, 2011 at 11:24 AM, Stuart Hughes <address@hidden> wrote:
> Hi Jon,
>
> This stuff is processed in config/userspace/toolchain.lkc which should
> be included in the BSP's config/platform/_target_/main.lkc file.
>
> Maybe whoever made this platform forgot to add it into the list of
> toolchains for that platform?  Which platform do you have selected?

Embedded Artists board with the NXP LPC3131

>
> Regards, Stuart
>
> On 21/10/11 15:05, address@hidden wrote:
>> On Fri, Oct 21, 2011 at 4:01 AM, Stuart Hughes <address@hidden> wrote:
>>> Hi Jon,
>>>
>>> I understand your frustration, however if you need NXP kernel patches
>>> integrated etc, you probably need to get a commercial agreement in place
>>> with them or some other entity to do this (or have a program to do this
>>> yourself).
>>>
>>> Regarding toolchains, you can use non-LTIB defined toolchains, provided you
>>> are aware of some potential pitfalls.
>>>
>>> First of all to do the selection, run:
>>>
>>> ./ltib -m config
>>>
>>> and then select under: "--- Toolchain selection." go to the next line and
>>> select the current toolchain and hit the enter key, you should see something
>>> like this (depending on BSP):
>>>
>>> (X) arm gcc-4.2.4 uClibc-0.9.30.1 soft float
>>> ( ) Custom
>>
>> I'm not getting the () Custom option when the NXP toolchains are enabled.
>>
>> I just did a cvs update
>>
>>>
>>> Use the arrow key and select custom and then enter.
>>>
>>> You now have these options:
>>>
>>>    Toolchain (Custom)  --->
>>> ()  Enter the custom toolchain path.
>>> ()  Enter the toolchain prefix
>>> ()  Enter any CFLAGS for gcc/g++
>>>
>>> For each one, enter the values for your toolchain.  For example they could
>>> be:
>>>
>>> /opt/z2/usr/local/gcc-4.2.4-uClibc-0.9.30.1-nfp-6/arm-linux-uclibc/usr
>>> arm-linux-uclibc-
>>> -msoft-float
>>>
>>> Now save this and then you could try to run: ./ltib
>>>
>>> The pitfall I spoke about is that the package baselibs.spec expects the
>>> toolchains to be built and laid out in a particular way.  The ones that are
>>> "known" are the CodeSourcery toolchains (of the vintage in LTIB) and also to
>>> some extent uClibc toolchains as were built when I was at Freescale.  If
>>> your toolchain is not laid out this way, you'll need to adjust the paths in
>>> the .spec file (you could override this locally in your
>>> config/platform/_target_ directory).  BTW: the purpose of baselibs is to
>>> copy the toolchain's target libraries to the target image (rather than
>>> re-building glibc/uclibc) so that you are guaranteed that the libs you build
>>> and run against match.
>>>
>>> Regards, Stuart
>>>
>>>
>>> On 20/10/11 14:41, address@hidden wrote:
>>>>
>>>> On Thu, Oct 20, 2011 at 3:55 AM, Stuart Hughes<address@hidden>  wrote:
>>>>>
>>>>> Hi Jon,
>>>>>
>>>>> Please don't preach.  This is well known, but there are good reasons not
>>>>> to
>>>>> do this. Mostly it comes down to time and money, a constraint many of us
>>>>> do
>>>>> have.
>>>>>
>>>>> Also there are many other reasons why this does not get done, so calm
>>>>> down a
>>>>> bit.  All this stuff is public and there if you wish to use it, otherwise
>>>>> use something else.
>>>>
>>>> A lot of developers are unaware of how badly this problem can bite
>>>> them until they build and ship a product that subsequently gets hacked
>>>> because of a security bug. In the past we have wasted large amounts of
>>>> money recovering from this problem and want to try and avoid it in the
>>>> future.
>>>>
>>>> On the positive side the current state of embedded support is far
>>>> better than it was five years ago.
>>>>
>>>> I'm just annoyed since forward porting uboot support for the lpc3130
>>>> has turned out to be very complicated. NXP wrote their own two stage
>>>> boot system which is proving hard to map onto the  model supplied by
>>>> current uboot. It can definitely be done but it is significant work.
>>>>
>>>> We want a current kernel and I was able to forward port the NXP kernel
>>>> patches in a couple of weeks. But there are changes in the way ARM
>>>> ATAGs are passed from uboot into the kernel which are addressed in a
>>>> more recent uboot. We are considering switching to a different CPU to
>>>> reduce the software load.
>>>>
>>>> A very useful option to add to ltib would be a simple config option to
>>>> use the ARM cross compilers already on the system (ie the Linaro ones
>>>> in Ubuntu). That would make it much easier to test with the current
>>>> compilers. I tried poking around in the scripts to add it but I
>>>> couldn't figure out how to do it.
>>>>
>>>>
>>>>> Regards, Stuart
>>>>>
>>>>> On 19/10/11 14:23, address@hidden wrote:
>>>>>>
>>>>>> Please submit any publicly useful changes you make to packages
>>>>>> upstream and don't carry the patches around in ltib for years. I am
>>>>>> spending a month right now trying to forward port the lpc313x uboot
>>>>>> changes up to current uboot. I've already brought the lpc313x changes
>>>>>> up to the current kernel and need a newer uboot to support it. If
>>>>>> those changes had been submitted upstream three years ago when they
>>>>>> were written I wouldn't have to be doing this.
>>>>>>
>>>>>> You really want changes submitted upstream. If you don't do it then
>>>>>> you get locked into the version of the program that you patched. You
>>>>>> may think that is saving you work by not having to hassle with the
>>>>>> submission. And that appearance will be true until a security hole is
>>>>>> found and patched in a latter version and your boss tells you that you
>>>>>> have to apply the patch. Now you have a mess. The patch is against a
>>>>>> latter version of the app that doesn't match your source code.
>>>>>>
>>>>>> To deal with the mess you either have to create your own private fork
>>>>>> where you apply security patches to your old, patched code (this is a
>>>>>> tower of cards that will fall as more patches accumulate) or you have
>>>>>> to forward port the your initial patch. You could have avoided all of
>>>>>> this by simply submitting the initial patch upstream. I've seen people
>>>>>> change jobs rather than deal with messes created by private forks.
>>>>>>
>>>>>> Of course you can choose to ignore the security patches. Do you know
>>>>>> how easy it is to hack something when you have the source code of the
>>>>>> patch fixing the vulnerability?
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>



-- 
Jon Smirl
address@hidden