February 2018 - kernelnewbies@kernelnewbies.org

where is __percpu_seg initialized?
by 落痕 March 28, 2018

March 28, 2018

Hi all: I knew the kernel implement the per-cpu variable via __percpu_seg. For example on x86 architecture, it's defined as: #ifdef CONFIG_X86_64 #define __percpu_seg gs #define __percpu_mov_op movq #else #define __percpu_seg fs #define __percpu_mov_op movl #endif But I'm curious where __percpu_seg is initialized?? I fail to find the relative code. Thanks.

2 2

Year 2038 time set problem
by techi eth March 1, 2018

March 1, 2018

Hi, Which Linux kernel version have Year 2038 problem solved for Linux running on 32 Bit system. https://en.wikipedia.org/wiki/Year_2038_problem

4 7

where __struct_cpy_bug is defined
by maoma king Feb. 27, 2018

Feb. 27, 2018

Dear all I find a function of __struct_cpy_bug in linux kernel v2.4.0.But I only it's declaration.I want to know where __struct_cpy_bug is defined

1 0

Re: Year 2038 time set problem
by Greg KH Feb. 27, 2018

Feb. 27, 2018

On Mon, Feb 26, 2018 at 02:15:53PM +0100, Piotr Figiel wrote: > Hi, > > 2018-02-24 16:50 GMT+01:00 Greg KH <greg(a)kroah.com>: > > Also note that the 4.1 kernel is very old and obsolete and insecure, and > > should NOT be used for any devices in the year 2038. > > According to kernel.org website 4.1 has projected EOL in May 2018. Yes, 3 months from now. > Is the information about kernel releases on kernel.org irrelevant/ > shouldn't be trusted? Or my understanding of longterm kernel trees is > incorrect? No, it is correct, but note that since 4.1.y is about to be end-of-life, it is receiving very few updates. No new device should be considering to use it for their kernel version because it will not be supported very soon now. In fact, if you are using 4.1.y, you have already been told to move off of it as soon as possible for this very reason. > Which trees do get security updates? The kernels listed on that page, but be aware that as the end-of-life time approaches, the releases and updates get very infrequent. You should always just update to a newer kernel version, or, if you are stuck at a specific kernel version due to some hardware or SoC requirements, get your support from that company as you are already paying for it. Hope this helps, greg k-h

2 2

Re: Security updates of Linux kernel (was: Re: Year 2038 time set problem)
by Greg KH Feb. 26, 2018

Feb. 26, 2018

On Mon, Feb 26, 2018 at 04:24:34PM +0100, Piotr Figiel wrote: > Hi, > > 2018-02-26 15:16 GMT+01:00 Greg KH <greg(a)kroah.com>: > > On Mon, Feb 26, 2018 at 02:15:53PM +0100, Piotr Figiel wrote: > >> 2018-02-24 16:50 GMT+01:00 Greg KH <greg(a)kroah.com>: > >> > Also note that the 4.1 kernel is very old and obsolete and insecure, and > >> > should NOT be used for any devices in the year 2038. > >> According to kernel.org website 4.1 has projected EOL in May 2018. > > Yes, 3 months from now. > >> Is the information about kernel releases on kernel.org irrelevant/ > >> shouldn't be trusted? Or my understanding of longterm kernel trees is > >> incorrect? > > No, it is correct, but note that since 4.1.y is about to be end-of-life, > > it is receiving very few updates. No new device should be considering > > to use it for their kernel version because it will not be supported very > > soon now. > > Yes, that's clear. I'm just concerned a bit that you wrote that 4.1 is > already insecure (while it's stated on kernel.org that it's currently > supported). I just wonder where is the boundary as to one can expect > the kernel to still get the security updates. It all depends. Right now, 4.1.y is vulnerable to the Spectre issue. As is 4.4.y. Will those kernels ever get those fixes, who knows, do you want to do the backport work, or just update to a newer kernel? And depending on your architecture, 4.4.y and 4.9.y is vunerable to Meltdown as well. And those kernels will not get fixed for known reasons I've documented elsewhere. There are other issues that are fixed in newer kernels that are not backported further back due to various issues, so you should always use a newer kernel release to be sure. > Is there a consensus about a reliable source of information which > kernels get fixes for certain security issues? Or is sticking with the > most recent /stable/ kernel the only recommended approach? This. > Commit messages often didn't mention any CVE or didn't indicate > clearly a security problem so it's pretty hard to track it > (semi-manually or automatically or without going in depth into commit > details). CVEs mean nothing, you can't rely on them. They are only good for if a bug is reported to the CVE numbering people, that's it. And even then, can you properly track a CVE issue that takes 100s of patches to resolve (like Meltdown and Spectre do?) I sure can not... For a full description on this whole thing, please see this post where I describe how the kernel developers treat "security" bugs, and how to ensure you are running a secure system: http://www.kroah.com/log/blog/2018/02/05/linux-kernel-release-model/ Hope this helps, greg k-h

3 3

Re: Year 2038 time set problem
by valdis.kletnieks＠vt.edu Feb. 26, 2018

Feb. 26, 2018

On Mon, 26 Feb 2018 14:15:53 +0100, Piotr Figiel said: > According to kernel.org website 4.1 has projected EOL in May 2018. Is > the information about kernel releases on kernel.org irrelevant/ > shouldn't be trusted? Or my understanding of longterm kernel trees is > incorrect? Do you *really* want to be doing any new development on something that goes off support in 3 months? Why are you even looking at 4.1? That was all the way back in June 2015, and since then, there have been 220,344 commits totalling: [/usr/src/linux] git diff --shortstat v4.1 v4.16-rc3 55263 files changed, 8740289 insertions(+), 2695706 deletions(-) (Heck, even my Raspberry Pi and my Linksys router are running 4.14 based kernels :) And feel free to 'name and shame' if a vendor is doing something that traps you at that release - that's a vendor behavior that should be discouraged.

2 1

Security updates of Linux kernel (was: Re: Year 2038 time set problem)
by Piotr Figiel Feb. 26, 2018

Feb. 26, 2018

Hi, 2018-02-26 15:16 GMT+01:00 Greg KH <greg(a)kroah.com>: > On Mon, Feb 26, 2018 at 02:15:53PM +0100, Piotr Figiel wrote: >> 2018-02-24 16:50 GMT+01:00 Greg KH <greg(a)kroah.com>: >> > Also note that the 4.1 kernel is very old and obsolete and insecure, and >> > should NOT be used for any devices in the year 2038. >> According to kernel.org website 4.1 has projected EOL in May 2018. > Yes, 3 months from now. >> Is the information about kernel releases on kernel.org irrelevant/ >> shouldn't be trusted? Or my understanding of longterm kernel trees is >> incorrect? > No, it is correct, but note that since 4.1.y is about to be end-of-life, > it is receiving very few updates. No new device should be considering > to use it for their kernel version because it will not be supported very > soon now. Yes, that's clear. I'm just concerned a bit that you wrote that 4.1 is already insecure (while it's stated on kernel.org that it's currently supported). I just wonder where is the boundary as to one can expect the kernel to still get the security updates. Is there a consensus about a reliable source of information which kernels get fixes for certain security issues? Or is sticking with the most recent /stable/ kernel the only recommended approach? Commit messages often didn't mention any CVE or didn't indicate clearly a security problem so it's pretty hard to track it (semi-manually or automatically or without going in depth into commit details). Thanks, Best regards, Piotr.

1 0

A question about decompressing kernel on boot
by 落痕 Feb. 26, 2018

Feb. 26, 2018

Hi list, In the source code arch/x86/boot/compressed/head_64.S, it described how compressed kernel is copied from the origin place to another pointed by rbx register. But I'm confused about the copying code, why it needs to minus 8 from _bss when calculating _bss original and new addresses. This is the source code. /* * Copy the compressed kernel to the end of our buffer * where decompression in place becomes safe. */ pushq %rsi leaq (_bss-8)(%rip), %rsi leaq (_bss-8)(%rbx), %rdi movq $_bss /* - $startup_32 */, %rcx shrq $3, %rcx std rep movsq cld popq %rsi Thanks, Larry

2 2

Invalid module format
by Srishti Sharma Feb. 25, 2018

Feb. 25, 2018

Hello, While trying to load a module from the linux-next branch , I get the error that the module format is invalid, this was because the kernel I compiled was different from the kernel I was trying to load the module into, so I installed the kernel from the same source as the module, and it booted for only once right after the installation. When I try to boot into the same kernel, my system reboots. What should I do so that I am able to boot into it everytime ? Regards, Srishti

3 7

Re: Invalid module format
by Alex Arvelaez Feb. 24, 2018

Feb. 24, 2018

On Feb 24, 2018 12:07 AM, Srishti Sharma <srishtishar(a)gmail.com> wrote: > > > > On Sat, Feb 24, 2018 at 4:59 AM, Tobin C. Harding <me(a)tobin.cc> wrote: >> >> On Thu, Feb 22, 2018 at 02:42:23AM +0530, Srishti Sharma wrote: >> > Hello, >> > >> > While trying to load a module from the linux-next branch >> >> Do you mean from linux-next tree or from a branch called linux-next in >> some other tree? (Not that it matters that much :) >> >> >, I get the error >> > that the module format is invalid, this was because the kernel I compiled >> > was different from the kernel I was trying to load the module into, so I >> > installed the kernel from the same source as the module, and it booted for >> > only once right after the installation. When I try to boot into the same >> > kernel, my system reboots. What should I do so that I am able to boot into >> > it everytime ? >> >> What are you trying to achieve? Are you doing testing on linux-next or >> do you just want to use the module? If you just want to use the module >> you could build the module for the current running kernel instead of >> rebuilding the kernel. Copy the module someplace and write a new >> makefile same as you would if you were developing your own [test] >> modules. >> >> (For the record I happened to be trying to learn about linux-next myself >> this morning and built a kernel that just goes into a reboot loop >> without even getting to the grub menu. It boots in a VM though so now >> I'm playing with the cofig.) >> > Something was wrong with the configuration file, so I copied the configuration of my running kernel and it boots now, but after running make, the modules don't get generated, so there is something I am missing in the configuration options again :( Are they getting built? did you do make modules_install? > Regards, > Srishti > > >> >> Hope this helps, >> Tobin. > > Regards, Alex

2 1