bootimg: Use FAT 32 for images larger than 512MB

Fixes [YOCTO #2138]

Commit 217584211625b1c496fe5b78aa4765ccf605d2b9 dropped the forced use
of FAT32 for the hddimg generation as it broke with very small images
(< 32MB). Unfortunately, left to its own devices, mkdosfs appears to select
FAT16 even for very large images, resulting in 2.2GB images being
generated as FAT16:

$ ls -lah core-image-lsb-sdk-atom-pc-20121010233936.hddimg
-rw-rw-r-- 1 dvhart dvhart 2.2G 2012-10-17 08:00 core-image-lsb-sdk-atom-pc-20121010233936.hddimg

$ file !$
file core-image-lsb-sdk-atom-pc-20121010233936.hddimg
core-image-lsb-sdk-atom-pc-20121010233936.hddimg: x86 boot sector, code offset 0x58, OEM-ID "SYSLINUX", sectors/cluster 128, root entries 512, Media descriptor 0xf8, sectors/FAT 138, heads 64, sectors 4502496 (volumes > 32 MB) , serial number 0x50761926, label: "boot       ", FAT (16 bit)

The result was a runtime boot error from SYSLINUX and a failure to boot
live images greater than 1GB in size.

While strictly speaking it is the cluster count that determines which
FAT size is used, that calculation requires more information than we
have readily available (such as sectors per cluster). If we let mkdosfs
determine sectors per cluster and just set a sane threshold above which
FAT32 is used, we get correct bootable images. With this patch the 2.2GB
core-image-lsb-sdk uses FAT32 and the 21 MB core-image-minimal uses
FAT16, and both boot in qemu successfully:

$ ls -lah tmp/deploy/images/core-image-lsb-sdk-atom-pc-20121212220835.hddimg
-rw-r--r-- 1 dvhart dvhart 2.2G 2012-12-12 14:18 tmp/deploy/images/core-image-lsb-sdk-atom-pc-20121212220835.hddimg

$ file !$
file tmp/deploy/images/core-image-lsb-sdk-atom-pc-20121212220835.hddimg
tmp/deploy/images/core-image-lsb-sdk-atom-pc-20121212220835.hddimg: x86 boot sector, code offset 0x58, OEM-ID "SYSLINUX", sectors/cluster 8, Media descriptor 0xf8, heads 64, sectors 4470304 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 4357, reserved3 0x800000, serial number 0x50c902b7, label: "boot       "

$ ls -lah tmp/deploy/images/core-image-minimal-atom-pc-20121212220600.hddimg
-rw-r--r-- 1 dvhart dvhart 21M 2012-12-12 14:06 tmp/deploy/images/core-image-minimal-atom-pc-20121212220600.hddimg

$ file !$
file tmp/deploy/images/core-image-minimal-atom-pc-20121212220600.hddimg
tmp/deploy/images/core-image-minimal-atom-pc-20121212220600.hddimg: x86 boot sector, code offset 0x58, OEM-ID "SYSLINUX", sectors/cluster 4, root entries 512, sectors 41408 (volumes <=32 MB) , Media descriptor 0xf8, sectors/FAT 41, heads 64, serial number 0x50c8ffec, label: "boot       ", FAT (16 bit)

I have tested and booted core-image-minimal and core-image-lsb-sdk for
atom-pc with qemu-system-i386 using this patch.

Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Cc: Steve Sakoman <steve@sakoman.com>
Cc: Joshua Immanuel <josh@hipro.co.in>
Cc: Przemek Czesnowicz <przemyslawx.czesnowicz@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Revert "initrdscripts: fix udevd in the live boot init scripts"

This cherry-pick slipped through testing and lead to unbootable hddimg images.

This reverts commit 0140519ba15bfb27ccbfb3d41c7e678a1118fc5c.

[ YOCTO #3634 ]

Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
libnss-mdns: fix mDNS resolving speed

We need to fix the "hosts: files dns mdns4" nsswitch.conf line
because for a .local lookup it does a DNS lookup first which will fail.
The recommended solution is:
hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4

[YOCTO #2502]

(From OE-Core rev: dbb350b90417962f2da4c1064ab0174badeb0f26)

Signed-off-by: Constantin Musca <constantinx.musca@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
cups: CVE-2012-5519

lpadmin to (limited) root privilege escalation
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-5519
http://www.cups.org/strfiles/4223/str4223v2-1.4.4-debian.patch

[YOCTO #3579]
[ CQID: WIND00392016 ]
Upstream-Status: Backport

(From OE-Core rev: 9f6964b489ef3e0f175bf33a94ab819408875da8)

Signed-off-by: Li Wang <li.wang@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
cups - CVE-2011-2896

the patch come from:
http://cups.org/strfiles/3867/str3867.patch

The LZW decompressor in the LWZReadByte function in giftoppm.c
in the David Koblas GIF decoder in PBMPLUS, as used in the
gif_read_lzw function in filter/image-gif.c in CUPS before 1.4.7,
the LZWReadByte function in plug-ins/common/file-gif-load.c
in GIMP 2.6.11 and earlier, the LZWReadByte function in img/gifread.c
in XPCE in SWI-Prolog 5.10.4 and earlier, and other products,
does not properly handle code words that are absent from the
decompression table when encountered, which allows remote attackers to
trigger an infinite loop or a heap-based buffer overflow, and possibly
execute arbitrary code, via a crafted compressed stream, a related
issue to CVE-2006-1168 and CVE-2011-2895.
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-2896

[YOCTO #3582]
[ CQID: WIND00299595 ]
Upstream-Status: Backport

(From OE-Core rev: 0742b7aecaada435f90f39f26914906a5eb1fd4f)

Signed-off-by: Li Wang <li.wang@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
cups CVE-2011-3170

the patch come from:
http://cups.org/strfiles/3914/str3914.patch

The gif_read_lzw function in filter/image-gif.c in CUPS 1.4.8 and
earlier does not properly handle the first code word in an LZW stream,
which allows remote attackers to trigger a heap-based buffer overflow,
and possibly execute arbitrary code, via a crafted stream, a different
vulnerability than CVE-2011-2896.
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-3170

[YOCTO #3583]
[ CQID: WIND00299594 ]
Upstream-Status: Backport

(From OE-Core rev: c82517bb667484854eaa05b6e9efd9ee0f164fec)

Signed-off-by: Li Wang <li.wang@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
librsvg: CVE-2011-3146

Store node type separately in RsvgNode

commit 34c95743ca692ea0e44778e41a7c0a129363de84 upstream

The node name (formerly RsvgNode:type) cannot be used to infer
the sub-type of RsvgNode that we're dealing with, since for unknown
elements we put type = node-name. This lead to a (potentially exploitable)
crash e.g. when the element name started with "fe" which tricked
the old code into considering it as a RsvgFilterPrimitive.
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-3146

https://bugzilla.gnome.org/show_bug.cgi?id=658014

[YOCTO #3581]
[ CQID: WIND00376773 ]
Upstream-Status: Backport

Signed-off-by: Li Wang <li.wang@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
arch-armv4.inc: add --fix-v4bx to TARGET_LD_KERNEL_ARCH only for armv4 and strongarm1100

* without this patch it does apply --fix-v4bx not only to armv4, but
  also all higher (because they also have armv4 in TUNE_FEATURES)
* it causes SIGILL on armv4t
  http://lists.linuxtogo.org/pipermail/openembedded-devel/2012-November/042298.html
* someone please test on armv4 device (I tested only bitbake -e output
  that it's correctly applied with DEFAULTTUNE == armv4
* maybe we can should fix this in binutils instead (both 2.22 and 2.23
  are affected)

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>