[gentoo-user] old kernels are installed during the upgrade

[gentoo-user] old kernels are installed during the upgrade

[Kruglov Sergey]

[-- Attachment #1: Type: text/plain, Size: 316 bytes --]

Hello, All!


Now I have  gentoo-sources-4.14.8-r1 installed.

After  "emerge --ask --update --deep --with-bdeps=y --newuse @world" command emerge installs old kernel in NS (after first update 4.12.12, after second update 4.9.49-r1).
How can I fix it?
There is sys-kernel/gentoo-sources in my world set.



[-- Attachment #2: Type: text/html, Size: 952 bytes --]

Re: [gentoo-user] old kernels are installed during the upgrade

[Alexander Kapshuk]

On Tue, Jan 2, 2018 at 1:54 PM, Kruglov Sergey <kr_serge@hotmail.com> wrote:
> Hello, All!
>
>
> Now I have  gentoo-sources-4.14.8-r1 installed.
>
> After  "emerge --ask --update --deep --with-bdeps=y --newuse @world" command
> emerge installs old kernel in NS (after first update 4.12.12, after second
> update 4.9.49-r1).
> How can I fix it?
> There is sys-kernel/gentoo-sources in my world set.
>
>

There was a discussion about this on the gentoo-dev mailing list. See
the link below for details:
https://archives.gentoo.org/gentoo-dev/message/1d2f3f98c2485fa53ed602bc8285054c

Re: [gentoo-user] old kernels are installed during the upgrade

[Mick]

[-- Attachment #1: Type: text/plain, Size: 1207 bytes --]

On Tuesday, 2 January 2018 12:03:24 GMT Alexander Kapshuk wrote:
> On Tue, Jan 2, 2018 at 1:54 PM, Kruglov Sergey <kr_serge@hotmail.com> wrote:
> > Hello, All!
> > 
> > 
> > Now I have  gentoo-sources-4.14.8-r1 installed.
> > 
> > After  "emerge --ask --update --deep --with-bdeps=y --newuse @world"
> > command emerge installs old kernel in NS (after first update 4.12.12,
> > after second update 4.9.49-r1).
> > How can I fix it?
> > There is sys-kernel/gentoo-sources in my world set.
> 
> There was a discussion about this on the gentoo-dev mailing list. See
> the link below for details:
> https://archives.gentoo.org/gentoo-dev/message/1d2f3f98c2485fa53ed602bc82850
> 54c

Alan copied a message from the devs list a few days ago, explaining that 
kernel 4.14 release has caused a lot of breakage and was keyworded for this 
reason.  Reverting to earlier releases is meant to address this.

That said, I've been running gentoo-sources-4.14.8-r1 here too, on 3 different 
boxen and thought it was doing fine, thanks.  Then I discovered KVM images 
failed to boot with this error:

kernel: kvm [5499]: vcpu0, guest rIP: 0xffffffffbbe67be4 disabled perfctr 
wrmsr: 0xc2 data 0xffff

:-/

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[gentoo-user] Re: old kernels are installed during the upgrade

[Nikos Chantziaras]

On 02/01/18 14:42, Mick wrote:
> On Tuesday, 2 January 2018 12:03:24 GMT Alexander Kapshuk wrote:
>> On Tue, Jan 2, 2018 at 1:54 PM, Kruglov Sergey <kr_serge@hotmail.com> wrote:
>>> [...]
>>> Now I have  gentoo-sources-4.14.8-r1 installed.
>>>
>>> After  "emerge --ask --update --deep --with-bdeps=y --newuse @world"
>>> command emerge installs old kernel in NS (after first update 4.12.12,
>>> after second update 4.9.49-r1).
>>> How can I fix it?
>>> [...]
>>
>> There was a discussion about this on the gentoo-dev mailing list. See
>> the link below for details:
>> https://archives.gentoo.org/gentoo-dev/message/1d2f3f98c2485fa53ed602bc82850
>> 54c
> 
> [...]
> That said, I've been running gentoo-sources-4.14.8-r1 here too, on 3 different
> boxen and thought it was doing fine, thanks.  Then I discovered KVM images
> failed to boot with this error:
> 
> kernel: kvm [5499]: vcpu0, guest rIP: 0xffffffffbbe67be4 disabled perfctr
> wrmsr: 0xc2 data 0xffff

The core issue seems to have been finally fixed in 4.14.10-r1.

Re: [gentoo-user] old kernels are installed during the upgrade

[Stroller]

> On 2 Jan 2018, at 11:54, Kruglov Sergey <kr_serge@hotmail.com> wrote:
> 
> Now I have  gentoo-sources-4.14.8-r1 installed.
> After  "emerge --ask --update --deep --with-bdeps=y --newuse @world" command emerge installs old kernel in NS (after first update 4.12.12, after second update 4.9.49-r1).
> How can I fix it?
> There is sys-kernel/gentoo-sources in my world set.

Remove sys-kernel/gentoo-sources from your world file - I believe you can do this using the emerge command, but am unsure of the right syntax; you can just edit /var/lib/portage/world and delete the appropriate line.D

Now `emerge -n =sys-kernel/gentoo-sources-4.14.8-r1` - "This option can be used to update the world file without  rebuilding the packages."

This pins your kernel version at 4.14.8-r1 and you can update when, in future, you decide it's time to update your kernel, without being nagged about it every time a new version is release or you emerge world.

For this reason it's always best to emerge kernels with an equals sign, pinning them at some specific version, IMO.

This suggestion may provoke responses that the kernel is important and you should update it to ensure you get security updates - look at the attack vectors, you're probably sitting behind a NAT router, with very few ports exposed to the internet.

It's adequate to update your kernel every 3 months.

Stroller.

Re: [gentoo-user] old kernels are installed during the upgrade

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 604 bytes --]

On Tue, 2 Jan 2018 11:54:50 +0000, Kruglov Sergey wrote:

> Now I have  gentoo-sources-4.14.8-r1 installed.
> 
> After  "emerge --ask --update --deep --with-bdeps=y --newuse @world"
> command emerge installs old kernel in NS (after first update 4.12.12,
> after second update 4.9.49-r1). How can I fix it? There is
> sys-kernel/gentoo-sources in my world set.

It's been keyworded because of issues discussed previously. Simply add 
"=sys-kernel/gentoo-sources-4.14.8-r1" (or .10-r1)
to /etc/portage/package.accept_keywords.


-- 
Neil Bothwick

Plagarism prohibited. Derive carefully.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] old kernels are installed during the upgrade

[Wols Lists]

On 02/01/18 19:26, Stroller wrote:
> 
>> On 2 Jan 2018, at 11:54, Kruglov Sergey <kr_serge@hotmail.com> wrote:
>>
>> Now I have  gentoo-sources-4.14.8-r1 installed.
>> After  "emerge --ask --update --deep --with-bdeps=y --newuse @world" command emerge installs old kernel in NS (after first update 4.12.12, after second update 4.9.49-r1).
>> How can I fix it?
>> There is sys-kernel/gentoo-sources in my world set.
> 
> Remove sys-kernel/gentoo-sources from your world file - I believe you can do this using the emerge command, but am unsure of the right syntax; you can just edit /var/lib/portage/world and delete the appropriate line.D
> 
> Now `emerge -n =sys-kernel/gentoo-sources-4.14.8-r1` - "This option can be used to update the world file without  rebuilding the packages."
> 
> This pins your kernel version at 4.14.8-r1 and you can update when, in future, you decide it's time to update your kernel, without being nagged about it every time a new version is release or you emerge world.
> 
> For this reason it's always best to emerge kernels with an equals sign, pinning them at some specific version, IMO.
> 
Why???

> This suggestion may provoke responses that the kernel is important and you should update it to ensure you get security updates - look at the attack vectors, you're probably sitting behind a NAT router, with very few ports exposed to the internet.
> 
> It's adequate to update your kernel every 3 months.
> 
You should also check the CVEs every time there's a new kernel!

What this completely misses, is that gentoo-sources merely DOWNLOADS THE
LATEST KERNEL SOURCE. So updating gentoo-sources every time does nothing
to change the kernel you are running.

Just leave gentoo-sources in your world file, and don't necessarily
compile and update your running kernel just because gentoo-sources has
had an update.

I normally do not clean out kernels from my grub.conf until I've built
up enough to be annoying, so downgrading a broken kernel is just a quick
edit away ...

Cheers,
Wol

[gentoo-user] Re: old kernels are installed during the upgrade

[Kai Krakow]

Am Tue, 02 Jan 2018 19:26:44 +0000 schrieb Stroller:

>> On 2 Jan 2018, at 11:54, Kruglov Sergey <kr_serge@hotmail.com> wrote:
>> 
>> Now I have  gentoo-sources-4.14.8-r1 installed.
>> After  "emerge --ask --update --deep --with-bdeps=y --newuse @world"
>> command emerge installs old kernel in NS (after first update 4.12.12,
>> after second update 4.9.49-r1).
>> How can I fix it?
>> There is sys-kernel/gentoo-sources in my world set.
> 
> Remove sys-kernel/gentoo-sources from your world file - I believe you
> can do this using the emerge command, but am unsure of the right syntax;
> you can just edit /var/lib/portage/world and delete the appropriate
> line.D

It is "emerge --deselect ...".


> Now `emerge -n =sys-kernel/gentoo-sources-4.14.8-r1` - "This option can
> be used to update the world file without  rebuilding the packages."

I don't think this is how it works. While technically correct, the 
outcome is different to what you're trying to achieve.


> This pins your kernel version at 4.14.8-r1 and you can update when, in
> future, you decide it's time to update your kernel, without being nagged
> about it every time a new version is release or you emerge world.

The equal sign doesn't pin versions, at least not that I remember. 
Package are pinned by slot in the world file. Coincidence may be that the 
version you selected happens to be exclusively the only slot, too.

If you intend to pin a package, either emerge by slot, or use 
package.mask and package.unmask.


> For this reason it's always best to emerge kernels with an equals sign,
> pinning them at some specific version, IMO.

Makes no sense if my above answer is correct.


> This suggestion may provoke responses that the kernel is important and
> you should update it to ensure you get security updates - look at the
> attack vectors, you're probably sitting behind a NAT router, with very
> few ports exposed to the internet.

The attack vector is probably not the network facing surface of the 
kernel... Which makes your argument misleading at best...

It is more likely that your kernel is attacked by something you did from 
the browser, or by running a server on one of the "few ports exposed" 
which is vulnerable, and that is the attack vector: A local privilege 
escalation or buffer overflow allowing the attacker to gain control of a 
process, and only then attacking the kernel.

This is why you first should keep your software updated and secured, and 
for the rest just stick to gentoo-sources stable.

Keep in mind that gentoo-sources back-ports some security fixes early. 
Also stable uses LTS kernels mostly which have long-term security 
maintenance.


> It's adequate to update your kernel every 3 months.

It's adequate to update your password every 3 months.

It's adequate to update your software every 3 months.

Really? No...

It's adequate to update your software when a security hole was fixed - on 
the point. Not two or three months later...

It gives a false impression of safety if you recommend such things.


Just my two cents... ;-)


-- 
Regards,
Kai

Replies to list-only preferred.

Re: [gentoo-user] Re: old kernels are installed during the upgrade

[Rich Freeman]

On Tue, Jan 2, 2018 at 3:20 PM, Kai Krakow <hurikhan77@gmail.com> wrote:
>
> It's adequate to update your software when a security hole was fixed - on
> the point. Not two or three months later...
>

And on that note I see that upstream just released 4.14.11 containing
what is widely speculated as a fix for an Intel CPU security
vulnerability.  I noticed that it doesn't disable the
performance-impacting setting on AMD CPUs.  Though, right now only AMD
could say whether this is necessary (their lkml post suggests it is
not).  This is an upstream release - I don't know when Gentoo plans to
release it.  I'm sure it will be making the rounds in the various news
sites any day.

-- 
Rich

Re: [gentoo-user] Re: old kernels are installed during the upgrade

[Adam Carter]

[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]

>
> And on that note I see that upstream just released 4.14.11 containing
> what is widely speculated as a fix for an Intel CPU security
> vulnerability.  I noticed that it doesn't disable the
> performance-impacting setting on AMD CPUs.  Though, right now only AMD
> could say whether this is necessary (their lkml post suggests it is
> not).  This is an upstream release - I don't know when Gentoo plans to
> release it.  I'm sure it will be making the rounds in the various news
> sites any day.
>

https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

"The effects are still being benchmarked, however we're looking at a
ballpark figure of five to 30 per cent slow down, depending on the task and
the processor model. More recent Intel chips have features – specifically,
PCID <http://forum.osdev.org/viewtopic.php?f=1&t=29935> – to reduce the
performance hit."

AMD coder's patch to disable the new code (to avoid the performance hit)
where he states the issue doesnt exist on AMD processors;
https://lkml.org/lkml/2017/12/27/2

[-- Attachment #2: Type: text/html, Size: 1824 bytes --]

Re: [gentoo-user] Re: old kernels are installed during the upgrade

[Wols Lists]

On 02/01/18 22:58, Adam Carter wrote:
> AMD coder's patch to disable the new code (to avoid the performance hit)
> where he states the issue doesnt exist on AMD processors;
> https://lkml.org/lkml/2017/12/27/2

Read LWN, specifically the links to the people who covered the bug.

It's a flaw in speculative forward processing, where the security does
not travel with the speculative processing. So user code can trigger a
page fault that references kernel code, causing that page to be
retrieved. OOPPSSSS. AMD keeps security context with the code, causing
an attempt to exploit the bug to fail with "invalid security context".

And as I understand it the code can be disabled with either a compile
time option or command line switch to the kernel. The relevant code is
called KAISER, which forces kernel and user address space into different
contexts, and causes a nasty context-switching overhead on both Intel
and AMD cpus.

Cheers,
Wol

Re: [gentoo-user] Re: old kernels are installed during the upgrade

[Rich Freeman]

On Wed, Jan 3, 2018 at 3:35 PM, Wols Lists <antlists@youngman.org.uk> wrote:
>
> And as I understand it the code can be disabled with either a compile
> time option or command line switch to the kernel.

I suspect the compile-time option is PAGE_TABLE_ISOLATION (which was
newly added in 4.14.11).  The command line option nopti will disable
it at runtime.

Rumor has it that it will be disabled on AMD CPUs in 4.14.12, but I
can't point to anywhere authoritative for that news so I'd consider it
a rumor.  I've also heard that Arch has deployed it early to 4.14.11,
and I wouldn't be surprised if many distros do this if it is intended
to go into the next stable, as there would be no point subjecting AMD
users to performance issues.  I haven't spoken to the Gentoo kernel
team about what their plans are for it.  In any case, nopti on the
command line is probably the cleanest solution.  I personally avoided
disabling the feature in the compiled kernel because I don't want to
be using the same config file on an Intel CPU in a year or two and
forget I have it forced off.

> The relevant code is
> called KAISER, which forces kernel and user address space into different
> contexts, and causes a nasty context-switching overhead on both Intel
> and AMD cpus.
>

I believe the kernel went with "Page Table Isolation (PTI)" rather
that KAISER, probably to avoid ethnic issues.  Apparently this was
deemed to have a more acceptable acronym than Forcefully Unmap
Complete Kernel With Interrupt Trampolines.

-- 
Rich

Re: [gentoo-user] old kernels are installed during the upgrade

[Stroller]

> On 2 Jan 2018, at 20:20, Kai Krakow <hurikhan77@gmail.com> wrote:
> 
> 
>> Now `emerge -n =sys-kernel/gentoo-sources-4.14.8-r1` - "This option can
>> be used to update the world file without  rebuilding the packages."
> 
> I don't think this is how it works. While technically correct, the 
> outcome is different to what you're trying to achieve.
> 
> 
>> This pins your kernel version at 4.14.8-r1 and you can update when, in
>> future, you decide it's time to update your kernel, without being nagged
>> about it every time a new version is release or you emerge world.
> 
> The equal sign doesn't pin versions, at least not that I remember. 
> Package are pinned by slot in the world file. Coincidence may be that the 
> version you selected happens to be exclusively the only slot, too.

It installs exactly that version, and that exact version is recorded in the world file.

$ grep -e source /var/lib/portage/world
sys-kernel/gentoo-sources:4.9.34
$ 

> It's adequate to update your software when a security hole was fixed - on 
> the point. Not two or three months later...
> 
> It gives a false impression of safety if you recommend such things.

We could spend every day updating our systems - IDK about you, but I have better things to do.

If the kernel devs cared to announce when they were patching exploits then we could take each one under consideration individually. But the kernel devs are secretive about kernel exploits, because they know there are literally millions of systems out there on the internet with kernels months and years old.

You're right about the attack vectors, which is why I prioritise the apps and servers I run - an attacker has to get past those before it can exploit those. I updated OpenSSH and openssl the day I leaned of the HeartBleed attack for example.

Meanwhile, I've seen security vulnerabilities go unfixed for literally weeks in the bug tracker, so I don't see the significance of a vulnerability an attacker is unlikely to be able to reach. The sites I visit do not make me fear my kernel being attacked via the browser.

This thread is not for arguing about security, which is an old discussion and which has been done to death. Everyone has their own opinions, and I'm not going to add any more.

This thread is about how to fix OP's problem, and that's what I addressed. If you install kernels by specific version, as I suggest, then you're free to update them manually as often as you wish.

Stroller.

Re: [gentoo-user] old kernels are installed during the upgrade

[Wols Lists]

On 03/01/18 21:21, Stroller wrote:
> Meanwhile, I've seen security vulnerabilities go unfixed for literally weeks in the bug tracker, so I don't see the significance of a vulnerability an attacker is unlikely to be able to reach. The sites I visit do not make me fear my kernel being attacked via the browser.
> 
> This thread is not for arguing about security, which is an old discussion and which has been done to death. Everyone has their own opinions, and I'm not going to add any more.
> 
> This thread is about how to fix OP's problem, and that's what I addressed. If you install kernels by specific version, as I suggest, then you're free to update them manually as often as you wish.

And heaven help you if you think emerging a specific version of
gentoo-sources will update the kernel you're running. Because Linux
certainly won't.

Hint: changing the current version of gentoo-sources does ABSOLUTELY
NOTHING to your running system, so why not emerge them all?

Cheers,
Wol

Re: [gentoo-user] old kernels are installed during the upgrade

[Stroller]

> On 2 Jan 2018, at 19:47, Wols Lists <antlists@youngman.org.uk> wrote:
> 
> You should also check the CVEs every time there's a new kernel!

Who the heck's got time for that? Really?

I have a life, mate. And that means I have better things to do with my time.

Translation of what you just said: you should buy a Mac, because Linux is so much work you have to check security bulletins all the time.

> What this completely misses, is that gentoo-sources merely DOWNLOADS THE
> LATEST KERNEL SOURCE. So updating gentoo-sources every time does nothing
> to change the kernel you are running.

I don't know why you think I missed that.

If you `emerge gentoo-sources` then updates of them will appear every time you --pretend update world until you allow them to be emerged, hence my use of the word "nagged".

If you want to install them, that's your prerogative, but just allowing them to be automatically emerged fills up your system with unwanted uncompressed kernel sources, consuming huge amounts of space.

20GB should be ample space for an operating system IMO, but between /usr/src and /usr/portage it's pretty easy to consume a quarter of that.

I'm happy to do things your way if you're contributing to my hosting bill, but from the sounds of it this is about the way YOU choose to administer YOUR systems, and that you think I should be deferential to that.

Do you not think, in my nearly 20 years of using *nix systems and reading *nix related mailing lists, I've never heard someone advocate these kind of security principles before?

These kind of arguments are theoretical. In the real world, there are millions of people still running Windows XP and now-obsolete versions of Android on their phones. A kernel that's a few months old is hardly likely to hurt me.

Stroller.
D

Re: [gentoo-user] old kernels are installed during the upgrade

[Stroller]

> On 3 Jan 2018, at 21:31, Wols Lists <antlists@youngman.org.uk> wrote:
> 
> And heaven help you if you think emerging a specific version of
> gentoo-sources will update the kernel you're running. Because Linux
> certainly won't.

Heaven help me?

Could you possibly clarify, please?

Stroller.

Re: [gentoo-user] old kernels are installed during the upgrade

[Rich Freeman]

On Wed, Jan 3, 2018 at 4:21 PM, Stroller <stroller@stellar.eclipse.co.uk> wrote:
>
> If the kernel devs cared to announce when they were patching exploits then we could take each
> one under consideration individually. But the kernel devs are secretive about kernel exploits, because
> they know there are literally millions of systems out there on the internet with kernels months and years old.
>

I'm skeptical of that claim.  I think it is more that they don't want
to try to track which commits are associated with CVEs.  I believe
they've said as much publicly.  They're not particularly secretive
about exploits except when they're under embargo (such as at the
present moment).

-- 
Rich

Re: [gentoo-user] old kernels are installed during the upgrade

[Dale]

Wols Lists wrote:
> On 03/01/18 21:21, Stroller wrote:
>> Meanwhile, I've seen security vulnerabilities go unfixed for literally weeks in the bug tracker, so I don't see the significance of a vulnerability an attacker is unlikely to be able to reach. The sites I visit do not make me fear my kernel being attacked via the browser.
>>
>> This thread is not for arguing about security, which is an old discussion and which has been done to death. Everyone has their own opinions, and I'm not going to add any more.
>>
>> This thread is about how to fix OP's problem, and that's what I addressed. If you install kernels by specific version, as I suggest, then you're free to update them manually as often as you wish.
> And heaven help you if you think emerging a specific version of
> gentoo-sources will update the kernel you're running. Because Linux
> certainly won't.
>
> Hint: changing the current version of gentoo-sources does ABSOLUTELY
> NOTHING to your running system, so why not emerge them all?
>
> Cheers,
> Wol
>
>

My question would be the opposite.  Why emerge kernels you are not going
to build anyway?  The only kernels I have installed here are the ones I
have emerged, built and installed for either current or future use. 
There is no reason to have sources for kernels that I know I will never
use.  The same could apply to others as well. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: old kernels are installed during the upgrade

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 456 bytes --]

On Wed, 3 Jan 2018 15:53:07 -0500, Rich Freeman wrote:

> I believe the kernel went with "Page Table Isolation (PTI)" rather
> that KAISER, probably to avoid ethnic issues.  Apparently this was
> deemed to have a more acceptable acronym than Forcefully Unmap
> Complete Kernel With Interrupt Trampolines.

ROFL!


-- 
Neil Bothwick

Q: How many accountants does it take to screw in a light bulb?
A: What kind of answer did you have in mind?

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] old kernels are installed during the upgrade

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1067 bytes --]

On Wed, 3 Jan 2018 21:21:30 +0000, Stroller wrote:

> >> This pins your kernel version at 4.14.8-r1 and you can update when,
> >> in future, you decide it's time to update your kernel, without being
> >> nagged about it every time a new version is release or you emerge
> >> world.  
> > 
> > The equal sign doesn't pin versions, at least not that I remember. 
> > Package are pinned by slot in the world file. Coincidence may be that
> > the version you selected happens to be exclusively the only slot,
> > too.  
> 
> It installs exactly that version, and that exact version is recorded in
> the world file.
> 
> $ grep -e source /var/lib/portage/world
> sys-kernel/gentoo-sources:4.9.34

That's not a version, it's a slot. Whilst kernels are currently slotted
with the version number, nothing else is and there is no guarantee that
this will also hold for kernels.

If you do want to use versions, I'd recommend using ~ rather than = to
pick up patch-level updates.


-- 
Neil Bothwick

I backed up my hard drive and ran into a bus.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] old kernels are installed during the upgrade

[Wols Lists]

On 03/01/18 21:39, Stroller wrote:
>> What this completely misses, is that gentoo-sources merely DOWNLOADS THE
>> > LATEST KERNEL SOURCE. So updating gentoo-sources every time does nothing
>> > to change the kernel you are running.

> I don't know why you think I missed that.

Because you're banging on like downloading the source is the same thing
as installing a new kernel - which it's not.
> 
> If you `emerge gentoo-sources` then updates of them will appear every time you --pretend update world until you allow them to be emerged, hence my use of the word "nagged".
> 
Which is why I just let them appear and clutter up /usr/src :-)

> If you want to install them, that's your prerogative, but just allowing them to be automatically emerged fills up your system with unwanted uncompressed kernel sources, consuming huge amounts of space.
> 
I take your point - you're paying for storage by the meg, and a quick du
-sh tells me a kernel is approx 1G - ouch.

But is the OP like you, or like me - about to upgrade from a home system
that already has 6TB of storage ...

> 20GB should be ample space for an operating system IMO, but between /usr/src and /usr/portage it's pretty easy to consume a quarter of that.

I remember when it fitted on an 8" floppy :-) It was bad enough
installing Slack from a 30-floppy set ...

What would be nice, would be if "emerge --depclean" had the smarts to
recognise that /usr/src/linux pointed to the current active kernel, and
didn't wipe that when it cleaned out everything else :-) That way, at
most you could have the current and latest kernel sources available
pretty easily.

Cheers,
Wol

Re: [gentoo-user] old kernels are installed during the upgrade

[Stroller]

> On 3 Jan 2018, at 21:55, Wols Lists <antlists@youngman.org.uk> wrote:
>  
> What would be nice, would be if "emerge --depclean" had the smarts to
> recognise that /usr/src/linux pointed to the current active kernel, and
> didn't wipe that when it cleaned out everything else :-) That way, at
> most you could have the current and latest kernel sources available
> pretty easily.

You've jogged a long-hibernating memory - the accidental removal of the current sources tree in an accident like this may be the exact reason why I refuse to allow kernel versions to be actively emerged.

Stroller.

Re: [gentoo-user] old kernels are installed during the upgrade

[Stroller]

> On 3 Jan 2018, at 21:53, Neil Bothwick <neil@digimed.co.uk> wrote:
>> 
>> It installs exactly that version, and that exact version is recorded in
>> the world file.
>> 
>> $ grep -e source /var/lib/portage/world
>> sys-kernel/gentoo-sources:4.9.34
> 
> That's not a version, it's a slot. Whilst kernels are currently slotted
> with the version number, nothing else is and there is no guarantee that
> this will also hold for kernels.

Fair enough, but there's nothing else I need to treat this way.

I guess this risks that emerge will try to install 4.9.34-r1 during a future update, but I don't believe I've ever experienced that.

> If you do want to use versions, I'd recommend using ~ rather than = to
> pick up patch-level updates.

What do you mean by this exactly, please?

Stroller.

Re: [gentoo-user] old kernels are installed during the upgrade

[Alan McKinnon]

On 04/01/2018 00:02, Stroller wrote:
> 
>> On 3 Jan 2018, at 21:55, Wols Lists <antlists@youngman.org.uk> wrote:
>>  
>> What would be nice, would be if "emerge --depclean" had the smarts to
>> recognise that /usr/src/linux pointed to the current active kernel, and
>> didn't wipe that when it cleaned out everything else :-) That way, at
>> most you could have the current and latest kernel sources available
>> pretty easily.
> 
> You've jogged a long-hibernating memory - the accidental removal of the current sources tree in an accident like this may be the exact reason why I refuse to allow kernel versions to be actively emerged.

I think that's a mountain and a molehill. You still have the image in
/boot, config in /boot or in the running kernel, libs in /lib/modules
and the bootloader is intact.

Delete the sources?
- Re-emerge them. 90 seconds.
- Re-compile using existing config. 20 minutes

So deleting the sources for the running kernel is a doh! moment. But no
biggie, and certainly not cause for changing your routine (all in my own
not at all humble opinion, of course)

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] old kernels are installed during the upgrade

[Alan McKinnon]

On 04/01/2018 00:07, Stroller wrote:
> 
>> On 3 Jan 2018, at 21:53, Neil Bothwick <neil@digimed.co.uk> wrote:
>>>
>>> It installs exactly that version, and that exact version is recorded in
>>> the world file.
>>>
>>> $ grep -e source /var/lib/portage/world
>>> sys-kernel/gentoo-sources:4.9.34
>>
>> That's not a version, it's a slot. Whilst kernels are currently slotted
>> with the version number, nothing else is and there is no guarantee that
>> this will also hold for kernels.
> 
> Fair enough, but there's nothing else I need to treat this way.
> 
> I guess this risks that emerge will try to install 4.9.34-r1 during a future update, but I don't believe I've ever experienced that.

Only if the highest-versioned emerged sources are <4.9.34-r1
> 
>> If you do want to use versions, I'd recommend using ~ rather than = to
>> pick up patch-level updates.
> 
> What do you mean by this exactly, please?

=4.9.34 selects that exact version and only that specific version
~4.9.34 select that version and also 4.9.34-r1. There might need to be a
* on the end of ~4.9.34, I don;t quite recall. Answer in portage's man pages


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] old kernels are installed during the upgrade

[Stroller]

> On 3 Jan 2018, at 22:11, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> 
>>>> 
>>>> $ grep -e source /var/lib/portage/world
>>>> sys-kernel/gentoo-sources:4.9.34
>>> ...
>> 
>> I guess this risks that emerge will try to install 4.9.34-r1 during a future update, but I don't believe I've ever experienced that.
> 
> Only if the highest-versioned emerged sources are <4.9.34-r1

Yes, in the quoted example above I grepped my world file for sources and 4.9.34 is currently installed. 

>> 
>>> If you do want to use versions, I'd recommend using ~ rather than = to
>>> pick up patch-level updates.
>> 
>> What do you mean by this exactly, please?
> 
> =4.9.34 selects that exact version and only that specific version
> ~4.9.34 select that version and also 4.9.34-r1. There might need to be a
> * on the end of ~4.9.34, I don;t quite recall. Answer in portage's man pages

I thought it was something like that, but searched `man portage` for "~" more than one way, and didn't find reference to this. Am I blind?

Stroller.

Re: [gentoo-user] old kernels are installed during the upgrade

[Alan McKinnon]

On 04/01/2018 00:41, Stroller wrote:
> 
>> On 3 Jan 2018, at 22:11, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>>
>>>>>
>>>>> $ grep -e source /var/lib/portage/world
>>>>> sys-kernel/gentoo-sources:4.9.34
>>>> ...
>>>
>>> I guess this risks that emerge will try to install 4.9.34-r1 during a future update, but I don't believe I've ever experienced that.
>>
>> Only if the highest-versioned emerged sources are <4.9.34-r1
> 
> Yes, in the quoted example above I grepped my world file for sources and 4.9.34 is currently installed. 
> 
>>>
>>>> If you do want to use versions, I'd recommend using ~ rather than = to
>>>> pick up patch-level updates.
>>>
>>> What do you mean by this exactly, please?
>>
>> =4.9.34 selects that exact version and only that specific version
>> ~4.9.34 select that version and also 4.9.34-r1. There might need to be a
>> * on the end of ~4.9.34, I don;t quite recall. Answer in portage's man pages
> 
> I thought it was something like that, but searched `man portage` for "~" more than one way, and didn't find reference to this. Am I blind?

man 5 ebuild

Section "Extended Atom Prefixes", it is near the top, probably first
page on most screen sizes.

The location is very non-obvious, I only know of it because I refr to it
often once I found it


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] old kernels are installed during the upgrade

[Herminio Hernandez, Jr.]

[-- Attachment #1: Type: text/plain, Size: 1257 bytes --]

I found this helpful in managing kernel versions

https://www.youtube.com/watch?v=UwvV2wf-Gk0

On Wed, Jan 3, 2018 at 3:41 PM, Stroller <stroller@stellar.eclipse.co.uk>
wrote:

>
> > On 3 Jan 2018, at 22:11, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> >
> >>>>
> >>>> $ grep -e source /var/lib/portage/world
> >>>> sys-kernel/gentoo-sources:4.9.34
> >>> ...
> >>
> >> I guess this risks that emerge will try to install 4.9.34-r1 during a
> future update, but I don't believe I've ever experienced that.
> >
> > Only if the highest-versioned emerged sources are <4.9.34-r1
>
> Yes, in the quoted example above I grepped my world file for sources and
> 4.9.34 is currently installed.
>
> >>
> >>> If you do want to use versions, I'd recommend using ~ rather than = to
> >>> pick up patch-level updates.
> >>
> >> What do you mean by this exactly, please?
> >
> > =4.9.34 selects that exact version and only that specific version
> > ~4.9.34 select that version and also 4.9.34-r1. There might need to be a
> > * on the end of ~4.9.34, I don;t quite recall. Answer in portage's man
> pages
>
> I thought it was something like that, but searched `man portage` for "~"
> more than one way, and didn't find reference to this. Am I blind?
>
> Stroller.
>
>
>

[-- Attachment #2: Type: text/html, Size: 2061 bytes --]

Re: [gentoo-user] old kernels are installed during the upgrade

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 476 bytes --]

On Wed, 3 Jan 2018 22:07:22 +0000, Stroller wrote:

> > If you do want to use versions, I'd recommend using ~ rather than = to
> > pick up patch-level updates.  
> 
> What do you mean by this exactly, please?

If you have =foo-1.0 matches only foo-1.0, if a patched version is
released as foo-1.0-r1, you won't get it. With ~foo-1.0 you will.

Neither will match foo-1.1

It's all in man portage.


-- 
Neil Bothwick

Only an idiot actually READS taglines.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] old kernels are installed during the upgrade

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 442 bytes --]

On Wed, 3 Jan 2018 22:02:37 +0000, Stroller wrote:

> You've jogged a long-hibernating memory - the accidental removal of the
> current sources tree in an accident like this may be the exact reason
> why I refuse to allow kernel versions to be actively emerged.

It's not a big deal, as Alan explained, but I use a set to prevent any
kernel sources being depcleaned.


-- 
Neil Bothwick

Grow your own dope, plant a politician!

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] old kernels are installed during the upgrade

[Stroller]

> On 3 Jan 2018, at 22:47, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> 
>>>> 
>>>> What do you mean by this exactly, please?
>>> 
>>> =4.9.34 selects that exact version and only that specific version
>>> ~4.9.34 select that version and also 4.9.34-r1. There might need to be a
>>> * on the end of ~4.9.34, I don;t quite recall. Answer in portage's man pages
>> 
>> I thought it was something like that, but searched `man portage` for "~" more than one way, and didn't find reference to this. Am I blind?
> 
> man 5 ebuild
> 
> Section "Extended Atom Prefixes", it is near the top, probably first
> page on most screen sizes.
> 
> The location is very non-obvious, I only know of it because I refr to it
> often once I found it

The ability to block atoms looks interesting, although I can't think when I'd use it.

Stroller.

Re: [gentoo-user] old kernels are installed during the upgrade

[Stroller]

> On 3 Jan 2018, at 23:41, Neil Bothwick <neil@digimed.co.uk> wrote:
> 
> On Wed, 3 Jan 2018 22:07:22 +0000, Stroller wrote:
> 
>>> If you do want to use versions, I'd recommend using ~ rather than = to
>>> pick up patch-level updates.  
>> 
>> What do you mean by this exactly, please?
> 
> If you have =foo-1.0 matches only foo-1.0, if a patched version is
> released as foo-1.0-r1, you won't get it. With ~foo-1.0 you will.
> 
> Neither will match foo-1.1

I would have guessed "~" means "approximate", but this is what I don't want.

If I want to recompile my kernel I'll choose the latest version and download the full sources.

Stroller.

Re: [gentoo-user] old kernels are installed during the upgrade

[Wols Lists]

On 03/01/18 22:09, Alan McKinnon wrote:
> On 04/01/2018 00:02, Stroller wrote:
>>
>>> On 3 Jan 2018, at 21:55, Wols Lists <antlists@youngman.org.uk> wrote:
>>>  
>>> What would be nice, would be if "emerge --depclean" had the smarts to
>>> recognise that /usr/src/linux pointed to the current active kernel, and
>>> didn't wipe that when it cleaned out everything else :-) That way, at
>>> most you could have the current and latest kernel sources available
>>> pretty easily.
>>
>> You've jogged a long-hibernating memory - the accidental removal of the current sources tree in an accident like this may be the exact reason why I refuse to allow kernel versions to be actively emerged.
> 
> I think that's a mountain and a molehill. You still have the image in
> /boot, config in /boot or in the running kernel, libs in /lib/modules
> and the bootloader is intact.
> 
> Delete the sources?
> - Re-emerge them. 90 seconds.
> - Re-compile using existing config. 20 minutes
> 
> So deleting the sources for the running kernel is a doh! moment. But no
> biggie, and certainly not cause for changing your routine (all in my own
> not at all humble opinion, of course)
> 
But it's a royal pain, especially if you don't realise that's what's
happened, because a general emerge is likely to have a lot of grief.

Dunno how many ebuilds actually refer to /usr/src/linux for some of
their header files, but I doubt it's negligible. It's certainly caused
me grief in the past.

(Yes I think they're not supposed to, but what's that saying about
theory and practice?)

I don't like it when well-known problems cause general breakage that is
likely to cause havoc for unsuspecting users...

Cheers,
Wol

Re: [gentoo-user] old kernels are installed during the upgrade

[Alan McKinnon]

On 04/01/2018 08:40, Wols Lists wrote:
> On 03/01/18 22:09, Alan McKinnon wrote:
>> On 04/01/2018 00:02, Stroller wrote:
>>>
>>>> On 3 Jan 2018, at 21:55, Wols Lists <antlists@youngman.org.uk> wrote:
>>>>  
>>>> What would be nice, would be if "emerge --depclean" had the smarts to
>>>> recognise that /usr/src/linux pointed to the current active kernel, and
>>>> didn't wipe that when it cleaned out everything else :-) That way, at
>>>> most you could have the current and latest kernel sources available
>>>> pretty easily.
>>>
>>> You've jogged a long-hibernating memory - the accidental removal of the current sources tree in an accident like this may be the exact reason why I refuse to allow kernel versions to be actively emerged.
>>
>> I think that's a mountain and a molehill. You still have the image in
>> /boot, config in /boot or in the running kernel, libs in /lib/modules
>> and the bootloader is intact.
>>
>> Delete the sources?
>> - Re-emerge them. 90 seconds.
>> - Re-compile using existing config. 20 minutes
>>
>> So deleting the sources for the running kernel is a doh! moment. But no
>> biggie, and certainly not cause for changing your routine (all in my own
>> not at all humble opinion, of course)
>>
> But it's a royal pain, especially if you don't realise that's what's
> happened, because a general emerge is likely to have a lot of grief.

Yes there is that

> 
> Dunno how many ebuilds actually refer to /usr/src/linux for some of
> their header files, but I doubt it's negligible. It's certainly caused
> me grief in the past.

It's a decidedly non-trivial number of ebuilds.

On Gentoo /usr/src is a symlink to the *configured* kernel sources, on
binary distros the same dir usually contains headers for the running kernel

> (Yes I think they're not supposed to, but what's that saying about
> theory and practice?)

I don't know of any documentation in Gentoo that says ebuilds shouldn't
do that but I can't think of any realistic alternatives. Gentoo needs
access to the kernel config not just the sources and we can't rely on a
config being present in /boot like binary distros can

> 
> I don't like it when well-known problems cause general breakage that is
> likely to cause havoc for unsuspecting users...

Gentoo has always had a fallback excuse position for devs:

By running Gentoo you give up all right to claiming to be an
"unsuspecting user"

Harsh I know, and sucky when it hits you, but it is what it is.
Gentoo is not for the faint-hearted



-- 
Alan McKinnon
alan.mckinnon@gmail.com

[gentoo-user] Re: old kernels are installed during the upgrade

[Holger Hoffstätte]

On Wed, 03 Jan 2018 15:53:07 -0500, Rich Freeman wrote:

> On Wed, Jan 3, 2018 at 3:35 PM, Wols Lists <antlists@youngman.org.uk> wrote:
>>
>> And as I understand it the code can be disabled with either a compile
>> time option or command line switch to the kernel.
> 
> I suspect the compile-time option is PAGE_TABLE_ISOLATION (which was
> newly added in 4.14.11).  The command line option nopti will disable
> it at runtime.
> 
> Rumor has it that it will be disabled on AMD CPUs in 4.14.12, but I

That's not a rumor and it can be easily verified either here:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-4.14/x86-cpu-x86-pti-do-not-enable-pti-on-amd-processors.patch

or in mainline git, respectively.

-h

Re: [gentoo-user] Re: old kernels are installed during the upgrade

[Rich Freeman]

On Thu, Jan 4, 2018 at 11:02 AM, Holger Hoffstätte
<holger@applied-asynchrony.com> wrote:
> On Wed, 03 Jan 2018 15:53:07 -0500, Rich Freeman wrote:
>
>> On Wed, Jan 3, 2018 at 3:35 PM, Wols Lists <antlists@youngman.org.uk> wrote:
>>>
>>> And as I understand it the code can be disabled with either a compile
>>> time option or command line switch to the kernel.
>>
>> I suspect the compile-time option is PAGE_TABLE_ISOLATION (which was
>> newly added in 4.14.11).  The command line option nopti will disable
>> it at runtime.
>>
>> Rumor has it that it will be disabled on AMD CPUs in 4.14.12, but I
>
> That's not a rumor and it can be easily verified either here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-4.14/x86-cpu-x86-pti-do-not-enable-pti-on-amd-processors.patch
>
> or in mainline git, respectively.
>

Not back when I made my post, as is evident from the timestamps.

All the info around these vulnerabilities is rapidly evolving, so take
anything you hear with some skepticism until the dust settles...

-- 
Rich

Re: [gentoo-user] Re: old kernels are installed during the upgrade

[Walter Dnes]

On Thu, Jan 04, 2018 at 11:10:01AM -0500, Rich Freeman wrote
> On Thu, Jan 4, 2018 at 11:02 AM, Holger Hoffstätte
> <holger@applied-asynchrony.com> wrote:
> > On Wed, 03 Jan 2018 15:53:07 -0500, Rich Freeman wrote:
> >
> >> On Wed, Jan 3, 2018 at 3:35 PM, Wols Lists <antlists@youngman.org.uk> wrote:
> >>>
> >>> And as I understand it the code can be disabled with either a compile
> >>> time option or command line switch to the kernel.
> >>
> >> I suspect the compile-time option is PAGE_TABLE_ISOLATION (which was
> >> newly added in 4.14.11).  The command line option nopti will disable
> >> it at runtime.
> >>
> >> Rumor has it that it will be disabled on AMD CPUs in 4.14.12, but I
> >
> > That's not a rumor and it can be easily verified either here:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-4.14/x86-cpu-x86-pti-do-not-enable-pti-on-amd-processors.patch
> >
> > or in mainline git, respectively.
> >
> 
> Not back when I made my post, as is evident from the timestamps.
> 
> All the info around these vulnerabilities is rapidly evolving, so take
> anything you hear with some skepticism until the dust settles...

  There are 2 vulnerabities at play here, both caused by speculative
execution...

1) "Meltdown" is the reading, by userland processes, of kernel memory.
This includes stuff like passwords, ssh and gpg keys, and other similar
sensitive stuff.  Intel is vulnerable; AMD is not, thanks to AMD's
ring-level permission checking.

2) "Spectre" is the reading, by one userland process, of memory
belonging to another userland process.  Since this does not require
jumping to kernel privilege level, AMD's ring-level permission checking
is not invoked, and AMD cpus are vulnerable.  Think "cross-site-scripting
on steroids", or "cross-process memory access" on your PC. 

  The most obvious attack vector would be web assembler or java plugin
or javascript, executing a 3rd-party ad in your browser.  By the way,
Adobe Flash is scripted by "Ecmascript", a variant of javascript.

  This is a problem that's associated with "speculative execution".  I
wonder how much of a performance hit it would be to turn off speculative
execution.  That would probably require at least a microcode/firmware
update, if not a new cpu.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Re: old kernels are installed during the upgrade

[Rich Freeman]

On Thu, Jan 4, 2018 at 9:12 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
>
>   There are 2 vulnerabities at play here, both caused by speculative
> execution...

Actually, there are 3 related ones, with two names between them.
Can't imagine why there is so much confusion...

> 2) "Spectre" is the reading, by one userland process, of memory
> belonging to another userland process.  Since this does not require
> jumping to kernel privilege level, AMD's ring-level permission checking
> is not invoked, and AMD cpus are vulnerable.  Think "cross-site-scripting
> on steroids", or "cross-process memory access" on your PC.

Spectre describes two variants.  It can be used from userland to
kernel, or between two userland processes.  However, it doesn't
require jumping priv levels - it is a side-channel leak.

Variant 1 requires that code be executed in the context of the process
being attacked.  So, there isn't a cross-priv issue here - just a
"skipped" bounds check.  When the out-of-bounds memory is accessed the
CPU sees that it is running in the correct priv level, which is
probably why AMD is vulnerable.

I'm a little hazy on variant 2, but I believe that this also requires
execution in the target context.  I suspect it doesn't run on AMD64
due to some details of how its CPUs actually work - it might not
speculatively do an indirect call, or it might not get far enough into
it to affect the cache.

>   This is a problem that's associated with "speculative execution".  I
> wonder how much of a performance hit it would be to turn off speculative
> execution.  That would probably require at least a microcode/firmware
> update, if not a new cpu.

Turning it off entirely would be a huge performance hit.  However,
Intel announced that they're going to add instructions to selectively
turn it off, presumably so that compilers can use this in situations
where Spectre is possible.  That will require a microcode change.  It
sounds like there are also workarounds.  For example, Intel suggests
doing an lfence after a bounds check to defeat variant 1, and I've
seen comments that suggest this works for some Intel users.  It
doesn't seem to work on my Phenom II or Ryzen 5.  Go figure, Intel
promoting an Intel-specific fix, though to be fair this is all rushed
and they might not even realize it doesn't work on AMD, or maybe I'm
doing it wrong.  (My code is at:
https://gist.github.com/rich0/056eebebc1f88a624e36680e0de36011 ).

-- 
Rich

Re: [gentoo-user] Re: old kernels are installed during the upgrade

[Walter Dnes]

  The most heavily exposed application will be your web browser.  It
runs various foreign code directly on your machine...

* web assembler
* java
* javascript
* ecmascript (part of Adobe Flash)

  I wonder if it's possible to compile a web browser with protection
against the exploits, but turn it off for other apps.  That would
protect against external attacks, while not hurting local app speed.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Re: old kernels are installed during the upgrade

[Rich Freeman]

On Fri, Jan 5, 2018 at 7:34 AM, Walter Dnes <waltdnes@waltdnes.org> wrote:
>
>   I wonder if it's possible to compile a web browser with protection
> against the exploits, but turn it off for other apps.  That would
> protect against external attacks, while not hurting local app speed.
>

There are three exploits, all requiring different solutions.  Only
exploit 3 has a solution which impacts speed.

Trying to fix exploit 3 in the browser seems dubious.  You'd need to
detect code patterns that could be trying to trigger the exploit
before they're run, because the CPU itself isn't going to provide any
protection here.  Exploit 3 is the only exploit that doesn't require
some kind of underlying vulnerability in a piece of software that is
being attacked (in addition to the CPU vulnerability).

Exploits 1/2 do require fixes in the browser already, but those don't
significantly impact performance.  Those fixes are also still being
worked on.

-- 
Rich