Kernel patches

Kernel patches

[Jacky Lam]

Hi,

    I want to make some statistics on all kernel patches. Could someone tell
me how can I gather all the patches sending to Linus, Alan Cox.....?
    Thanks.

Jacky

Re: Kernel patches

[Andreas Dilger]

On Mar 09, 2002  01:23 +0800, Jacky Lam wrote:
>     I want to make some statistics on all kernel patches. Could someone tell
> me how can I gather all the patches sending to Linus, Alan Cox.....?

Search mail archives for the subject [PATCH].  Note that it would be
very difficult to correlate _submitted_ patches with _accepted_ patches,
unless you had some smarts to detect that a later kernel had that patch
applied.  That is complicated by the fact that submitted and applied
patches are not always exactly the same.

Cheers, Andreas
--
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

kernel patches

[Chris Babcock]

Since the selinux project doesn't apply any patches to the distributed
kernel, what kernel patches have those who have been having good success
with selinux been using?

Also, I have seen some vocal opposition to the current implementation of
LSM in 2.5 on lklm.  Has there been any resolution, and where does this
put selinux on 2.5?

-Chris

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: kernel patches

[Russell Coker]

On Tue, 13 May 2003 03:26, Chris Babcock wrote:
> Since the selinux project doesn't apply any patches to the distributed
> kernel, what kernel patches have those who have been having good success
> with selinux been using?

I have (with some work) got SE Linux running on ARM machines and UML.

Patches that have worked without effort include the speedtouch ADSL driver, 
ipvs, Cobalt Qube and RaQ patch, crypto-loopback device, and SKAS for UML.

Generally small patches just work, but big patches often don't apply cleanly.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: kernel patches

[Stephen Smalley]

On Mon, 2003-05-12 at 13:26, Chris Babcock wrote:
> Also, I have seen some vocal opposition to the current implementation of
> LSM in 2.5 on lklm.  Has there been any resolution, and where does this
> put selinux on 2.5?

LSM is still in mainline 2.5, recently submitted patches that add
support for the use of extended attributes by security modules have been
merged, and a recently submitted patch that adds support for a process
attribute API has been queued up for merging.  RFCs on the SELinux
module have also been posted to lkml, and we plan on submitting SELinux
for merging once the process attribute API patch and the security
initcall patch make their way into mainline.  The most significant
objection to LSM has appeared to be the lack of any real security
modules in mainline that use it; this should be addressed by the merging
of SELinux.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

kernel patches

[Sona Sarmadi]

Hi all,

I wonder how you handle the kernel patches? 

I want to apply a security kernel patch to Linux-yocto 3.10  which is used by Romely:

meta-inte/meta-romley/conf/machine/romley-ivb.conf:PREFERRED_VERSION_linux-yocto ?= "3.10%"

For me the obvious way to fix this is:
1) Create >> "poky/meta/recipes-kernel/linux/files" directory and add the patch file there

2) modify: poky/meta/recipes-kernel/linux/linux-yocto_3.10.bb


-SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.10.git;bareclone=1;branch=${KBRANCH},${KMETA};name=machine,meta"
+FILESEXTRAPATHS_prepend := "${THISDIR}/files:"

+SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.10.git;bareclone=1;branch=${KBRANCH},${KMETA};name=machine,meta \
+          file://Fix_for_CVE-2014-0196_pty_layer_race_condition.patch \
+          "

Please let me know if this is the correct way. And also let me know if I upstream this kernel patch to yocto, will yocto accept it (if the patch looks correct of course). Please let me know if you prefer to apply security patches to kernels in some different way.

Thanks
BR - Sona

Re: kernel patches

[Bruce Ashfield]

On 14-08-22 08:17 AM, Sona Sarmadi wrote:
> Hi all,
>
> I wonder how you handle the kernel patches?
>
> I want to apply a security kernel patch to Linux-yocto 3.10  which is used by Romely:
>
> meta-inte/meta-romley/conf/machine/romley-ivb.conf:PREFERRED_VERSION_linux-yocto ?= "3.10%"
>
> For me the obvious way to fix this is:
> 1) Create >> "poky/meta/recipes-kernel/linux/files" directory and add the patch file there
>
> 2) modify: poky/meta/recipes-kernel/linux/linux-yocto_3.10.bb
>
>
> -SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.10.git;bareclone=1;branch=${KBRANCH},${KMETA};name=machine,meta"
> +FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
>
> +SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.10.git;bareclone=1;branch=${KBRANCH},${KMETA};name=machine,meta \
> +          file://Fix_for_CVE-2014-0196_pty_layer_race_condition.patch \
> +          "
>
> Please let me know if this is the correct way. And also let me know if I upstream this kernel patch to yocto, will yocto accept it (if the patch looks correct of course). Please let me know if you prefer to apply security patches to kernels in some different way.

If this is for your own local builds, a layer with a bbappend and the
patches is a better idea.

For the main linux-yocto recipes, everything is maintained in the
git repositories, not patched at build time, so changes go to the
linux-yocto mailing list, and I merge them from there.

On this particular topic, I already track all the -stable updates for
our linux-yocto kernels, and CVEs are picked up by -stable. So there's
a process in place to get security related fixes into the linux-yocto
trees.

I'm a few releases behind at the moment, due to a 2 week vacation,
but 3.4, 3.10 and 3.14 will all be updated shortly.

If you do notice a CVE that isn't part of the k.org -stable updates,
that is or more interest, and we should nominate it for -stable upstream
and have it flow to all kernels via that process.

Bruce

>
> Thanks
> BR - Sona
>

Re: kernel patches

[Sona Sarmadi]

Bruce,
Thanks for quick response. See inline my comments.

Have a nice weekend
/Sona

>> Please let me know if this is the correct way. And also let me know if I upstream this kernel patch to yocto, will yocto accept it (if the patch looks correct > of course). Please let me know if you prefer to apply security patches to kernels in some different way.

> If this is for your own local builds, a layer with a bbappend and the patches is a better idea.
Sona: No this is not local, I wanted to backport a security patch from 3.15 to lLinux Yoctp 3.14 and upstreamed to Yocto.

> For the main linux-yocto recipes, everything is maintained in the git repositories, not patched at build time, so changes go to the linux-yocto mailing list, and I merge them from there.

> On this particular topic, I already track all the -stable updates for our linux-yocto kernels, and CVEs are picked up by -stable. So there's a process in place to get security related fixes into the linux-yocto trees.
Sona: very good :)

> I'm a few releases behind at the moment, due to a 2 week vacation, but 3.4, 3.10 and 3.14 will all be updated shortly.
Sona: So if a security patch is only fixed in later versions, you don't want to backport the fix to older yocto versions (e.g.3.10, 3.14) even if the bug is present in these versions. You rather prefer to inherit these from k.org. 
   

> If you do notice a CVE that isn't part of the k.org -stable updates, that is or more interest, and we should nominate it for -stable upstream and have it > flow to all kernels via that process.

Sona: I see, this would be a better approach.  

> Bruce

Re: kernel patches

[Bruce Ashfield]

On 14-08-22 12:02 PM, Sona Sarmadi wrote:
> Bruce,
> Thanks for quick response. See inline my comments.
>
> Have a nice weekend
> /Sona
>
>>> Please let me know if this is the correct way. And also let me know if I upstream this kernel patch to yocto, will yocto accept it (if the patch looks correct > of course). Please let me know if you prefer to apply security patches to kernels in some different way.
>
>> If this is for your own local builds, a layer with a bbappend and the patches is a better idea.
> Sona: No this is not local, I wanted to backport a security patch from 3.15 to lLinux Yoctp 3.14 and upstreamed to Yocto.
>
>> For the main linux-yocto recipes, everything is maintained in the git repositories, not patched at build time, so changes go to the linux-yocto mailing list, and I merge them from there.
>
>> On this particular topic, I already track all the -stable updates for our linux-yocto kernels, and CVEs are picked up by -stable. So there's a process in place to get security related fixes into the linux-yocto trees.
> Sona: very good :)
>
>> I'm a few releases behind at the moment, due to a 2 week vacation, but 3.4, 3.10 and 3.14 will all be updated shortly.
> Sona: So if a security patch is only fixed in later versions, you don't want to backport the fix to older yocto versions (e.g.3.10, 3.14) even if the bug is present in these versions. You rather prefer to inherit these from k.org.

We are at a slight advantage in this area, since we've moved to a model
of releasing and supporting the LTSI kernel versions. As such, they
continue to get korg stable maintenance for a cycle that matches our
Yocto support window.

That means there are few, if any, CVEs that don't get addressed via
the flow I described.

That being said, if there's a linux-yocto kernel version that isn't
LTSI and isn't get standard korg -stable updates (i.e. the non-LTSI
kernel version that will be released with Yocto 1.7), then backported
fixes to that version can come to the linux-yocto list, and I can
apply them to the tree.

Cheers,

Bruce

>
>
>> If you do notice a CVE that isn't part of the k.org -stable updates, that is or more interest, and we should nominate it for -stable upstream and have it > flow to all kernels via that process.
>
> Sona: I see, this would be a better approach.
>
>> Bruce
>