Re: Debian Developers Have Been Listening!

[Michael Fothergill]

On 18 May 2017 at 17:48, Patrick Bartek  wrote:

>
> A while ago, I initiated the "If Linux Is About Choice ..." thread
> about why there is no choice of inits during an initial install.
>
> Since that time, I've tested several systemd-less distros[1] as well as
> Stretch as replacements for my aging Wheezy system.  With Stretch my
> plan was to see if I could replace systemd as the init without removing
> it just leaving its components (some or all as necessary) to meet
> dependencies without it breaking the system  That way there would be no
> need for third party repos or jumping through hoops to keep a
> systemd-less working. I figured it would be a somewhat difficult, time
> consuming process. However, I made a discovery during these tests: The
> Debian developers had already done it for me.  They made switching from
> systemd as the init to sysvinit or runit easy just by issuing a couple
> commands. Here's what you do.
>
> First, install Stretch as you normally would, systemd, et al.  I chose
> LXDE for the GUI as it has no direct systemd dependencies, and it uses
> Openbox as the window manager which I normally use in lieu of a desktop
> environment anyway.  This was quicker and easier testing-wise than
> starting with a terminal-based system as I normally would, and building
> up from there.
>
> To switch to sysvinit, as root:
>
>   apt-get install sysvinit-core
>
> and reboot.  Done!  systemd components are still on the hard drive,
> except systemd-sysv has been removed.  There is also no systemd
> supervision either as far as I can tell.
>
> To switch to runit-init is an easy 2-step process.  Do a standard
> install as before.[2]  Then add runit supervision first before
> installing runit-init. As root:
>
>   apt-get install runit-systemd
>
> reboot, then
>
>   apt-get install runit-init
>
> Reboot. Done!  The latter command removes systemd-sysv during the
> install.
>
> These new init set ups survive apt-get upgrade or dist-upgrade even if
> systemd components are upgraded.  Systemd as init does not get
> reactivated.  Tested and verified.  I can find no systemd pinning
> either.
>
> I now have two Stretch systems running in VirtualBox.  One a full LXDE
> desktop using runit for both the init and supervision, and the other
> with just Openbox and lxpanel as the GUI, and sysvinit and runit for
> supervison. No problems at all with either.
>
>
> B
>
> ​Well, I'll be hornswaggled.  Hallelujah!

MF  ​




> [1] AntiX, MX Linux, SalixOS and Void Linux.
>
> [2] With either above options, you can't go from an init other than
> systemd to another init.  apt-get install  fails due to
> systemd-sysv being missing.
>
>

Re: Debian Developers Have Been Listening!

[Michael Fothergill]

On 18 May 2017 at 18:03, Dominik George  wrote:

> Hi,
>
> >A while ago, I initiated the "If Linux Is About Choice ..." thread
> >about why there is no choice of inits during an initial install.
> >
> >Since that time, I've tested several systemd-less distros[1] as well as
> >Stretch as replacements for my aging Wheezy system.  With Stretch my
> >plan was to see if I could replace systemd as the init without removing
> >it just leaving its components (some or all as necessary) to meet
> >dependencies without it breaking the system  That way there would be no
> >need for third party repos or jumping through hoops to keep a
> >systemd-less working. I figured it would be a somewhat difficult, time
> >consuming process. However, I made a discovery during these tests: The
> >Debian developers had already done it for me.  They made switching from
> >systemd as the init to sysvinit or runit easy just by issuing a couple
> >commands.
>
> Thanks for sharing your experiences!
>
> Don't get me wrong, but the interesting part is that this has already been
> the exact case long before your thread, and it is what you were told
> several times throughout the discussion ;).
>
> Long story short, not so many reasons for all the excitement :).
>

​If this is true and it is a doddle to convert an ordinary debian install
with systemd running on it to the old sysvinit format then why is there all
this sturm und drang and spam on this subject...??

MF​



>
> -nik
>
>

Re: Debian Developers Have Been Listening!

[Michael Fothergill]

On 20 May 2017 at 14:43, Cat  wrote:

> On Sat, May 20, 2017 at 02:20:15PM +0100, Michael Fothergill wrote:
> > If this is true and it is a doddle to convert an ordinary debian install
> > with systemd running on it to the old sysvinit format then why is there
> all
> > this sturm und drang and spam on this subject...??
>
> Fanaticism. For some it is not enough that it not be process 1. There can
> not
> be a single solitary trace of it on the system. Anywhere. At all.
>
> Purity above all.
>

​So, when I read some emails that sounded like there was a problem
upgrading to a newer version of debian etc on a large number of networked
machines connected to a server ​and I then began to think about how you
would switch to running e.g. Gentoo or some other Linux distro and even
tried posting something in an effort to be helpful, that was all pointless
and I was being subtly trolled

In fact what was really required was some psychotherapy instead.

Oh well

MF






>
> --
>   "A search of his car uncovered pornography, a homemade sex aid, women's
>   stockings and a Jack Russell terrier."
> - http://www.dailytelegraph.com.au/news/wacky/indeed/story-
> e6frev20-118083480
>

Re: Debian Developers Have Been Listening!

[Michael Fothergill]

On 20 May 2017 at 15:59, Brad Rogers  wrote:

> On Sat, 20 May 2017 14:20:15 +0100
> Michael Fothergill  wrote:
>
> Hello Michael,
>
> >with systemd running on it to the old sysvinit format then why is there
> >all this sturm und drang and spam on this subject...??
>
> People complain about all sorts of things.  Changing something.  Not
> changing something.  Sometimes, it's even the same people.
>

​Now I see why the developers have their own mailing list...

MF​


>
> --
>  Regards  _
>  / )   "The blindingly obvious is
> / _)radnever immediately apparent"
> Why do they try to hide our past pulling down houses and build car parks
> Bricks & Mortar - The Jam
>

Re: Debian Developers Have Been Listening!

[Michael Fothergill]

On 20 May 2017 at 14:43, Cat  wrote:

> On Sat, May 20, 2017 at 02:20:15PM +0100, Michael Fothergill wrote:
> > If this is true and it is a doddle to convert an ordinary debian install
> > with systemd running on it to the old sysvinit format then why is there
> all
> > this sturm und drang and spam on this subject...??
>
> Fanaticism. For some it is not enough that it not be process 1. There can
> not
> be a single solitary trace of it on the system. Anywhere. At all.
>
> Purity above all.
>

​I think they should get to know some people who contracted a Clostridium
difficile infection and had a stool transplant​.

See here:

​https://en.wikipedia.org/wiki/Fecal_microbiota_transplant​


​I guess they see system "as a System difficile" infection, but the
developers have created their version of the stool transplant that works
just fine.

Problem solved.

MF​

>
> --
>   "A search of his car uncovered pornography, a homemade sex aid, women's
>   stockings and a Jack Russell terrier."
> - http://www.dailytelegraph.com.au/news/wacky/indeed/story-
> e6frev20-118083480
>

Re: Debian Developers Have Been Listening!

[Michael Fothergill]

On 23 May 2017 at 22:19, Patrick Bartek  wrote:

> On Mon, 22 May 2017 08:30:15 +0900 Joel Rees 
> wrote:
>
> > On Fri, May 19, 2017 at 1:48 AM, Patrick Bartek 
> > wrote:
> > >
> > > A while ago, I initiated the "If Linux Is About Choice ..." thread
> > > about why there is no choice of inits during an initial install.
> > >
> > > Since that time, I've tested several systemd-less distros[1] as
> > > well as Stretch as replacements for my aging Wheezy system.  With
> > > Stretch my plan was to see if I could replace systemd as the init
> > > without removing it just leaving its components (some or all as
> > > necessary) to meet dependencies without it breaking the system
> >
> > ???
>
> Could you be a little more specific?  Or should I?
>
> > > That way there would be no
> > > need for third party repos or jumping through hoops to keep a
> > > systemd-less working. I figured it would be a somewhat difficult,
> > > time consuming process. However, I made a discovery during these
> > > tests: The Debian developers had already done it for me.  They made
> > > switching from systemd as the init to sysvinit or runit easy just
> > > by issuing a couple commands. Here's what you do.
> >
> > I thought that information came out several times in the thread you
> > mention having started -- that it was possible to install the base
> > system, then disable and remove the main systemd component, just
> > leaving some of the pieces that have been picked up as dependencies
> > by other packages.
>
> That scenerio was mentioned and was known by me, but usually used to
> prevent systemd from being installed all.  But since Debian is now
> systemd dependent and doing that will cause problems.  You either have
> to use third party repos or compile stuff yourself, have local repos,
> etc just to get things to work.  I ended up with a simplier solution:
> Just treat systemd like any other dependency, then no special repos,
> compiling, etc.  And it worked!  And the Stretch developers made it
> easy to do which wasn't available with Jessie. Thank you developers.
>

​I am moved to tears by this.  It is a tribute to human ingenuity, to
conflict resolution, to WHO mental health goals
and at the same time it represents a subtle troll bamboozling and
befuddling spam filter for the list here.

My God Bless you all!

MF​



>
> My original thread was on why there is no choice of init at install
> time. You have choices on almost everything else. Anyway, most of the
> answers were ambiguous, a few acrimonious.  No matter.
>
> > Maybe the discussion of using more advanced techniques to keep from
> > ever installing systemd in the first place hid the information about
> > the removal approach.
>
> Too many hoops to jump through to eliminate systemd if major
> components (GNOME, udev, udisks2, policykit-1, etc) have it (or parts of
> it) as dependencies.  Just look at all Devuan had to go through to do
> it.
>
> > If so, it would seem to be worthwhile to have this separate thread,
> > as well.
>
> I don't think it would do any good.  Debian has chosen systemd, for
> better or worse, and I don't see that changing.  Users and
> administrators will either adapt or adopt another distro.
>
> I just hope my little "fix" is useful to someone else.  FWIW, I found
> without systemd as the init and supervisor, I have about 7.5 MB more
> free RAM.
>
> B
>
>

Re: Debian Developers Have Been Listening!

[Michael Fothergill]

On 24 May 2017 at 16:22, Patrick Bartek  wrote:

> On Tue, 23 May 2017 18:45:16 -0500 David Wright
>  wrote:
>
> > On Tue 23 May 2017 at 13:42:07 (-0700), Patrick Bartek wrote:
> >
> > > It's easier, simplistic even, to replace systemd as the init (with
> > > sysvinit or runit-init) in Stretch than it was with Jessie.
> >
> > I hope you mean simple, and not that you're being simplistic!
> >
> > Cheers,
> > David.
>
> Right.  That should have been "simpler."


​I feel suitably mollified.

MF​


> I should proof read my posts
> better.
>
> B
>
>

Re: Debian installation issues

[Michael Fothergill]

On 8 June 2017 at 05:34, David DLC  wrote:

> Hello,
>
> I have been trying to install Debian Jessie for about a week now. I have a
> 64-bit Windows 10 PC. I have shrunk the main C drive by 25 gbs, and turned
> off fast boot. I downloaded the AMD-64 small CD iso, and used win32 disk
> imager to write it to a 2 gb usb stick. However, when I boot my computer
> from the disk, I get the error message "The selected boot device failed.
> Press  to continue." I tried another program, Rufus, to write the
> image file. There was no difference even when I tried that. I am at a
> complete loss at what to do. I don't know if it's a problem with my
> computer, or if I am doing something incorrectly.
>

​Hi there.  Try booting up and loading the bios.  Check that it is sniffing
around for usb sticks and DVD's etc by default before trying to boot from
the hard drive.  If the default is the hard drive you need to change the
boot order to include the device ie DVD drive or USB stick etc.

It sounds like that might not be the problem here but it is worth checking
anyway.

If you have a DVD drive in the PC try burning the iso onto it and booting
from it instead and see what happens.

Cheers

Michael Fothergill
​


>
> Any help would be much appreciated.
>
> Thank you
>

Re: Debian installation issues

[Michael Fothergill]

On 8 June 2017 at 17:08, David DLC  wrote:

> Thank you for all the replies! I haven't really used a mailing list
> before, so I'm not 100% sure I'm responding to the correct location. Do I
> hit "reply all" or just reply to the debian-user@lists.debian.org address?
>
> Anyway, I have disabled secure boot, but that didn't seem to solve the
> problem. My computer does not have a DVD drive, so I put the ISO (
> debian-8.8.0-amd64-netinst.iso) on a USB stick. When booting my computer,
> I specifically click "use a device", then "USB Drive (UEFI)". The computer
> runs for a minute, then pops up the error message. I don't think boot order
> would change this, as I am booting specifically from the USB. I forgot to
> mention that I am attempting to dual boot my computer, so I don't wish to
> remove Windows completely.
>
> I have also tried rewriting the ISO multiple times, with both the complete
> and smaller installation sets. I can try another USB stick, but I don't
> have any lying around and would likely need to purchase a new one.
>
>
​You are posting correctly as far as I can see.  I have used Rufus and it
worked easily.  I assume that your usb stick works OK to store files in the
conventional way.

I have found that I needed to repeat usb stick iso file burning or whatever
term you use for it; sometimes it didn't work ie wouldn't boot from it the
first time - try wiping the stick and using Rufus again to burn the iso
onto it and have another go.

Cheers

MF
​


> I have attached the system info if anyone would like to take a look:
>
> OS Name Microsoft Windows 10 Home
> Version 10.0.14393 Build 14393
> Other OS Description  Not Available
> OS Manufacturer Microsoft Corporation
> System Name DAVIDDLC
> System Manufacturer Hewlett-Packard
> System Model HP Spectre XT TouchSmart PC
> System Type x64-based PC
> System SKU C2M71UA#ABA
> Processor Intel(R) Core(TM) i7-3517U CPU @ 1.90GHz, 2401 Mhz, 2 Core(s),
> 4 Logical Processor(s)
> BIOS Version/Date Insyde F.04, 11/10/2012
> SMBIOS Version 2.7
> Embedded Controller Version 68.57
> BIOS Mode UEFI
> BaseBoard Manufacturer Hewlett-Packard
> BaseBoard Model Not Available
> BaseBoard Name Base Board
> Platform Role Mobile
> Secure Boot State Off
> PCR7 Configuration Binding Not Possible
> Windows Directory C:\WINDOWS
> System Directory C:\WINDOWS\system32
> Boot Device \Device\HarddiskVolume2
> Locale United States
> Hardware Abstraction Layer Version = "10.0.14393.206"
> User Name DAVIDDLC\Other_2
> Time Zone Central Daylight Time
> Installed Physical Memory (RAM) 8.00 GB
> Total Physical Memory 7.90 GB
> Available Physical Memory 5.79 GB
> Total Virtual Memory 9.15 GB
> Available Virtual Memory 7.08 GB
> Page File Space 1.25 GB
> Page File C:\pagefile.sys
> Hyper-V - VM Monitor Mode Extensions Yes
> Hyper-V - Second Level Address Translation Extensions Yes
> Hyper-V - Virtualization Enabled in Firmware No
> Hyper-V - Data Execution Protection Yes
>

Re: Debian installation issues

[Michael Fothergill]

On 8 June 2017 at 17:52, David DLC  wrote:

> Thank you for the info on the mailing address.
>
> > The #debian bot currently recommends  iskimager/>
> > if you need to write the Debian install image to a USB device from
> > Windows.
>
> I actually used that program to write the ISO to the USB stick the first
> time I tried it, but it didn't work.
>
> > I have found that I needed to repeat usb stick iso file burning or
> whatever term you use for it; sometimes it didn't work ie wouldn't boot
> from it the first time - try wiping the stick and using Rufus again to burn
> the iso onto it and have > another go.
>
> I tried to rewrite the file, but it still did not work correctly. I don't
> know what is going on. I can't get the Debian installation page to appear,
> no matter what I do.
>

​Find a buddy who has an external DVD drive..

Attach it to your machine, burn the iso to a DVD and then boot from
it...

Cheers

MF​


>
> On Thu, Jun 8, 2017 at 11:17 AM, Greg Wooledge 
> wrote:
>
>> On Thu, Jun 08, 2017 at 11:08:32AM -0500, David DLC wrote:
>> > Thank you for all the replies! I haven't really used a mailing list
>> before,
>> > so I'm not 100% sure I'm responding to the correct location. Do I hit
>> > "reply all" or just reply to the debian-user@lists.debian.org address?
>>
>> For this mailing list, you are expected to reply only to the list address,
>> unless the person to whom you're replying explicitly requests personal
>> responses.  (This is different from most other technical support mailing
>> lists in the world, where the expectation is "reply all".)
>>
>> > Anyway, I have disabled secure boot, but that didn't seem to solve the
>> > problem. My computer does not have a DVD drive, so I put the ISO (
>> > debian-8.8.0-amd64-netinst.iso) on a USB stick. When booting my
>> computer, I
>> > specifically click "use a device", then "USB Drive (UEFI)". The computer
>> > runs for a minute, then pops up the error message. I don't think boot
>> order
>> > would change this, as I am booting specifically from the USB. I forgot
>> to
>> > mention that I am attempting to dual boot my computer, so I don't wish
>> to
>> > remove Windows completely.
>>
>> If you used Windows to put the ISO image onto the USB stick, it's
>> quite possible it wasn't done correctly.
>>
>> The #debian bot currently recommends > iskimager/>
>> if you need to write the Debian install image to a USB device from
>> Windows.
>>
>> If you're doing it from a Unix/Linux system, then follow the
>> instructions at .
>>
>>
>

Re: Debian installation issues

[Michael Fothergill]

On 8 June 2017 at 17:57, Michael Fothergill 
wrote:

>
>
> On 8 June 2017 at 17:52, David DLC  wrote:
>
>> Thank you for the info on the mailing address.
>>
>> > The #debian bot currently recommends <http://sf.net/projects/win32d
>> iskimager/>
>> > if you need to write the Debian install image to a USB device from
>> > Windows.
>>
>> I actually used that program to write the ISO to the USB stick the first
>> time I tried it, but it didn't work.
>>
>> > I have found that I needed to repeat usb stick iso file burning or
>> whatever term you use for it; sometimes it didn't work ie wouldn't boot
>> from it the first time - try wiping the stick and using Rufus again to burn
>> the iso onto it and have > another go.
>>
>> I tried to rewrite the file, but it still did not work correctly. I don't
>> know what is going on. I can't get the Debian installation page to appear,
>> no matter what I do.
>>
>
> ​Find a buddy who has an external DVD drive..
>
> Attach it to your machine, burn the iso to a DVD and then boot from
> it...
>
> Cheers
>
> MF​
>

​PS If you have a buddy who uses Linux distros ask them to see if they can
get your usb stick to work in their machine ie you can boot debian from it.

Some usb sticks are easier than others to boot from I have found.

​Once you know that stick works, try it on your machine.

If that still doesn't work, then go for the external drive plan B option
above.

Regards

MF


​

​


>
>
>>
>> On Thu, Jun 8, 2017 at 11:17 AM, Greg Wooledge 
>> wrote:
>>
>>> On Thu, Jun 08, 2017 at 11:08:32AM -0500, David DLC wrote:
>>> > Thank you for all the replies! I haven't really used a mailing list
>>> before,
>>> > so I'm not 100% sure I'm responding to the correct location. Do I hit
>>> > "reply all" or just reply to the debian-user@lists.debian.org address?
>>>
>>> For this mailing list, you are expected to reply only to the list
>>> address,
>>> unless the person to whom you're replying explicitly requests personal
>>> responses.  (This is different from most other technical support mailing
>>> lists in the world, where the expectation is "reply all".)
>>>
>>> > Anyway, I have disabled secure boot, but that didn't seem to solve the
>>> > problem. My computer does not have a DVD drive, so I put the ISO (
>>> > debian-8.8.0-amd64-netinst.iso) on a USB stick. When booting my
>>> computer, I
>>> > specifically click "use a device", then "USB Drive (UEFI)". The
>>> computer
>>> > runs for a minute, then pops up the error message. I don't think boot
>>> order
>>> > would change this, as I am booting specifically from the USB. I forgot
>>> to
>>> > mention that I am attempting to dual boot my computer, so I don't wish
>>> to
>>> > remove Windows completely.
>>>
>>> If you used Windows to put the ISO image onto the USB stick, it's
>>> quite possible it wasn't done correctly.
>>>
>>> The #debian bot currently recommends <http://sf.net/projects/win32d
>>> iskimager/>
>>> if you need to write the Debian install image to a USB device from
>>> Windows.
>>>
>>> If you're doing it from a Unix/Linux system, then follow the
>>> instructions at <http://www.debian.org/releases/stable/amd64/ch04s03>.
>>>
>>>
>>
>

Re: Debian installation issues

[Michael Fothergill]

On 9 June 2017 at 08:01, Fungi4All  wrote:

>
> UTC Time: June 8, 2017 4:17 PM
> From: wool...@eeg.ccf.org
>
> On Thu, Jun 08, 2017 at 11:08:32AM -0500, David DLC wrote:
> > Thank you for all the replies! I haven't really used a mailing list
> before,
> > so I'm not 100% sure I'm responding to the correct location. Do I hit
> > "reply all" or just reply to the debian-user@lists.debian.org address?
>
> For this mailing list, you are expected to ..
>
>
> whaaat ever 
>
> > Anyway, I have disabled secure boot, but that didn't seem to solve the
> > problem. My computer does not have a DVD drive, so I put the ISO (
> > debian-8.8.0-amd64-netinst.iso) on a USB stick. When booting my
> computer, I
> > specifically click "use a device", then "USB Drive (UEFI)". The computer
> > runs for a minute, then pops up the error message. I don't think boot
> order
> > would change this, as I am booting specifically from the USB. I forgot to
> > mention that I am attempting to dual boot my computer, so I don't wish to
> > remove Windows completely.
>
> If you used Windows to put the ISO image onto the USB stick, it's
> quite possible it wasn't done correctly.
>
>
> Get used to Greg on this list making vague assumptions on things and
> blaming the victim for anything the victim is having problems with, never
> the system.  The system must not be challenged.
> In trying to convince others to switch from windows to a better and higher
> performing system, despite of hardware, one must learn to work with windows
> to begin with, because nobody is willing to wipe everything they have off
> and start with a clean disk.
> Rufus in my experience has been 100% reliable in burning images of all
> sorts.  It is small and fast.  If in reverse try from linux to burn an
> ms-win-installation image, chances are that you will fail despite of what
> way you may try to do so.  Propbably Thomas from xorisso fame can explain
> better the whys and why nots.  I give up trying to understand the reasons.
> Let's hope you do not live in isolation, there are others with a pc around
> you and not all run win10.  Try and boot your stick in their system, no
> harm can be done if you don't install anythin.  If by any chance you make a
> debian-live-installation image you may even get to see debian come a-live
> without an installation.
> Since the debian world is really poor in applied technical information
> location, try the ubuntu (askubuntu) for help/faq.  It is a friendlier
> environment and easier to find solutions.  99% of what you will find there
> works for debian too.  Especially on this specific issue there is a ton of
> instructions.
>
> The #debian bot currently recommends  win32diskimager/>
> if you need to write the Debian install image to a USB device from
> Windows.
>
>
> I am willing to bet the image written through rufus is fine, your problem
> is booting up from usb as people have mentioned before.  I like to assume
> that you did not install win10 in an older pc but bought a recent pc with
> win10 in it. The following will not help you "fix your problem" but it is
> more like talking about THE problem so your frustration is not misdirected
> to the wrong direction.
> MS with win10, using the excuse of a protection of your system, managed to
> effectively block other systems of getting installed next to win10.
>

​Is this really the case?  I use windows 10 and it does not stop me running
a triple boot system on a single disk.

Try using grub2win: https://sourceforge.net/projects/grub2win/  - install
it in windows 10 and play around with it and see if you can get it to see
your usb stick.

Regards

MF




> So ms to promote themselves and diminish competition (what's new?) did
> what they did.  Then they manhandled manufacturers to incorporate their
> evil into what they sell to you.  And you paid for this problem to your
> ventor.  Did you know when you purchased your product and license you
> became part of the problem people are addressing to solve?
> Why not a worldwide class action suit against manufacturers, vendors, and
> retailers of all sorts for not warning you the product is nearly useless
> without win10?  Thanks to some who resist and make and sell linux based
> products off the shelf.  Let's not talk about fruit vendors here.
> If not, you deserve what you got, and I am sorry to have to tell you.  I
> think you should go back to whoever sold you a lemon for an apple and make
> them either pay you back what you paid of install Debian for you on your
> partition.  It should only take 20' not several days.
> Ohhh... you accepted some license that told you so in the fine print?  I
> am sorry!  Really   keep paying for problems you distribute around.
>
> If you're doing it from a Unix/Linux system, then follow the
> instructions at 
>
>
> I have given up reading any documentation from debian, it is all written
> by developers for eng

Re: Debian installation issues

[Michael Fothergill]

On 9 June 2017 at 20:59, Fungi4All  wrote:

> Here is some relevant reading of installing linux system besides Win8 and
> in some cases the same problem exists on Win 10.
> https://askubuntu.com/questions/221835/installing-ubuntu-alongside-a-pre-
> installed-windows-with-uefi
>


​I read through some of this.  If I understood it correctly, if you buy a
machine that comes with e.g. Windows 10 installed for you then this secure
boot feature would make it difficult to boot and install certain Linux
distributions - but some versions of Ubuntu might be OK apparently.

But if you would buy such a machine, do you not also get the Windows key
codes for the OS...?

If you do, then could you not just back up the work files on the
installation and then uninstall Windows and reinstall it with the secure
boot feature turned off and then install the Linux distro of your choice?

When I get a new PC I specifically request that it has no operating system
on it and then install everything from scratch.

I have not encountered this problem as yet.

Cheers

MF









>
> Ok, MS did what they did, but manufacturers accepted this and incorporated
> it into their product which you pay.
> It is like paying for an MS only system without knowing it.
>

Re: Debian installation issues

[Michael Fothergill]

On 10 June 2017 at 14:05, Richard Owlett  wrote:

> On 06/09/2017 03:37 PM, Michael Fothergill wrote:
>
>> On 9 June 2017 at 20:59, Fungi4All  wrote:
>>
>> Here is some relevant reading of installing linux system besides Win8 and
>>> in some cases the same problem exists on Win 10.
>>> https://askubuntu.com/questions/221835/installing-ubuntu-
>>> alongside-a-pre-
>>> installed-windows-with-uefi
>>>
>>>
>>
>> ​I read through some of this.  If I understood it correctly, if you buy a
>> machine that comes with e.g. Windows 10 installed for you then this secure
>> boot feature would make it difficult to boot and install certain Linux
>> distributions - but some versions of Ubuntu might be OK apparently.
>>
>> But if you would buy such a machine, do you not also get the Windows key
>> codes for the OS...?
>>
>> If you do, then could you not just back up the work files on the
>> installation and then uninstall Windows and reinstall it with the
>> secure boot feature turned off and then install the Linux distro
>> of your choice?
>>
>> When I get a new PC I specifically request that it has no operating
>> system on it and then install everything from scratch.
>>
>
> I follow a variation on that that suits my personal/idiosyncratic
> preferences for buying used/reconditioned hardware (no need for cutting
> edge) and buying locally rather than online (fewer communication snafus).
>
> I go into the store with a live DVD or flash drive. I began doing this to
> see if a standard install of Debian had appropriate drivers. I found a
> secondary advantage in discovering how straight forward it was to boot from
> something other than the default hard disk. A couple months ago I had
> occasion to go one step further and while and do a full install while in
> the store (odd permutation of hardware and software).
> YMMV
>
>
>
>> I have not encountered this problem as yet.
>>
>
> I'm not clear to what "this problem" refers.
>

​As I understand it, it is possible to purchase a PC or laptop which has
Windows 10 preinstalled on the hard drive.

Apparently the default installation in a UEFI capable machine includes
something called the "secure boot" facility.  This new feature makes
installing Linux distros difficult in some cases.
We have been trying to help the OP with this problem.

Regards

MF

​


>
>
>> Cheers
>>
>> MF
>>
>
>
>
>

Re: Debian installer not finding free space

[Michael Fothergill]

On 13 June 2017 at 10:20, Dan Purgert  wrote:

> David DLC wrote:
> > [...]
> > I have 40 gb unallocated on my C drive currently. When I start up the
> > installer and get to the disk partitioning section, it cannot find the
> > free space in the "guided" section. Am I doing something wrong with
> > the disk management?
>
> If it's MBR partitioned, you're already using up your four (4)
> partitions (OS (C:\) ; Recovery(400MB); RECOVERY (D:\); Recovery
> (800MB); and I'm not 100% sure if the EFI partition counts against you
> too).
>
>
> You would need to remove some of those partitions, and set up an extended
> partition container in order to create logical partitions which you can
> then install Debian to.
>

​Unlike Ubuntu which I think can find a way to make space within the
windows partitions to install itself, I don't think Debian has that option.

I am not sure if you would need to reinstall Windows and reduce the
partition sizes to create free disk space that the installer will see and
make use of.

Perhaps if you nobble the two recovery partitions that won't make Windows
unusable.  If you could then install debian in the space freed up when you
reboot into Windows it will discover that the recovery partitions are gone
but there is no space in which to recreate them.   I think that Windows
might then reorganise things to reduce the C drive partition size and allow
new recovery partitions to be created. I am not 100% sure on this but you
could google it and check.

Regards

MF
​


>
> Though, since you already have four (five if we count the EFI
> partition), perhaps the drive is already GPT partitioned ...
>
>
> --
> |_|O|_| Registered Linux user #585947
> |_|_|O| Github: https://github.com/dpurgert
> |O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281
>
>

Re: Why does no one care that Brad Spengler of GRSecurity is blatantly violating the intention of the rightsholders to the Linux Kernel?

[Michael Fothergill]

On 15 June 2017 at 21:38, deloptes  wrote:

> Richard Owlett wrote:
>
> > On 06/15/2017 02:10 PM, rhkra...@gmail.com wrote:
> >> Hmm, am I feeding the spammer?  [snip]
> >
> > Likely
> >
> >>
> >> PS: aconcernedfossdev doesn't "command" much respect in my mind,
> >> especially with no better explanation of the problem than what I read
> >> here.
> >
> > +1
>
> The story behind is really interesting and pretty long. I read about the
> conflict perhaps 1/2y ago. Some of the accusations by GRSec make sense,
> however they do not justify their policy.
> In fact this is the best proof (IMO) how decentralized and open
> idea/project/work etc fails. It fails on both ends the Linux and the GRSec
> end because the first is not motivated to do good and the second to do good
> for free it fails badly.
> I do however think GRSec are wrong as the OP states, they clearly violate
> the license agreements.
> IMO everyone in the linux community should know the background of that
> story
> same as the background of systemd ... but there is sooo much to know
>

​When I read the OP's rhetorical question:​

​Why does not one person here care?​


​I was moved to say: because they are obsessed with systemd ​

​But you have beaten me to the punch in a subtle way which I am both
impressed and humbled by.

MF​

regards
>
>
>
>

Re: Why does no one care that Brad Spengler of GRSecurity is blatantly violating the intention of the rightsholders to the Linux Kernel?

[Michael Fothergill]

On 15 June 2017 at 16:41,  wrote:

> Why does no one care that Brad Spengler of GRSecurity is blatantly
> violating the intention of the rightsholders to the Linux Kernel?
> He is also violating the license grant, Courts would not be fooled by his
> scheme to prevent redistribution.
>
> The license grant the Linux Kernel is distributed under disallows the
> imposition of additional terms. The making of an understanding that the
> derivative work must not be redistributed (lest there be retaliation) is
> the imposition of an additional term. The communication of this threat is
> the moment that GRSecurity violates the license grant. Thence-forth
> modification, making of derivative works, and distribution of such is a
> violation of the Copyright statute. The concoction of the transparent
> scheme shows that it is a willful violation, one taken in full knowledge by
> GRSecurity of the intention of the original grantor.
>
>
> Why does not one person here care?
>

​because we are all suffering from troll envy...

The pseudo-angst ridden discussions about systemd on the site here are not
quite as  seductive as this post...

We can feign some fake outrage and bask in it for a time and then decide
that we must "get a life" as Bill Shatner advised the trekkies all those
years ago.

Where would we be without spam and trolling?

MF
​


> Just want to forget what holds Libre Software together and go the way of
> BSD?
>
>
> (Note: last month the GRSecurity Team removed the public testing patch,
> they prevent the distribution of the patch by paying customers by a
> threat of no further business: they have concocted a transparent scheme
> to make sure the intention of the Linux rights-holders (thousands of
> entities) are defeated) (This is unlike RedHat who do distribute their
> patches in the form the rights-holders prefer: source code, RedHat does
> not attempt to stymie the redistribution of their derivative works,
> GRSecurity does.).
>
> --
> ( This song is about GRSecurity's violation of Linus et al's copyright**:
> youtube.com/watch?v=CYnhI3wUej8
> (A Boat Sails Away 2016 17) )
>
>
>

Re: Remotely exploitable bug in systemd (CVE-2017-9445)

[Michael Fothergill]

On 2 July 2017 at 09:26, Sven Joachim  wrote:

> On 2017-07-02 09:34 +0200, Pascal Hambourg wrote:
>
> > Le 01/07/2017 à 23:19, Sven Joachim a écrit :
> >> On 2017-07-01 16:36 -0400, Perry E. Metzger wrote:
> >>
> >>> Am I correct in interpreting this:
> >>> https://security-tracker.debian.org/tracker/CVE-2017-9445
> >>> as meaning a fix to it still isn't in sid, and therefore is not
> >>> yet in the process of percolating down to stretch?
> >>
> >> That seems to be correct.
>

​Could this be exploited to force people to use sysvinit instead of systemd
?

Not that I am paranoid about such things of course.

MF​




> >
> > Huh ? Do *stable* security updates have to go through sid ?
>
> No.  However, as there will be no upload by the security team, the
> maintainers will have to provide an update via proposed-updates, and the
> release team usually demands that the bug is fixed in unstable first.
>
> Cheers,
>Sven
>
>

Re: Replace systemd

[Michael Fothergill]

On 3 July 2017 at 21:39, Greg Wooledge  wrote:

> On Mon, Jul 03, 2017 at 08:42:11PM +0100, Rory Campbell-Lange wrote:
> > Simply put; systemd doesn't suit me. Its a bit like being asked to use
> > an graphical editor instead of vi. Or being forced to use Windows. My
> > laptop doesn't feel like my machine anymore.
> >
> > Is there a pure Debian alternative?
>
> You may switch to one of the other init systems.  Assuming stretch
> (Debian 9):
>
> To use sysvinit, simply "apt-get install sysvinit-core" and reboot.
>

​I am greatly humbled by the serene unflappable way that you made this
suggestion..

As the Buddha said:

Greater in battle than the man who would conquer a thousand-thousand men,
is he who would conquer just one —
himself.
​
​Would that I could learn to walk in such company.

MF​



> To use runit, "apt-get install runit-systemd", reboot, "apt-get install
> runit-init", and reboot again.
>
>

Re: Einstellungen in Kontact

[Michael Fothergill]

​Dear Sir,

Please use a German mailing list.

Regds

MF

​

Zieht den Bayern die Lederhosen aus

Voller Spannung und voller Spass,
leg ich mich ins grüne Gras.
Es ist Samstag und wir können feiern,
heute kommt der FC Bayern.
Alle sind hier guter Dinge,
und überall hört man sie singen:

Zieht den Bayern die Lederhosen aus, Lederhosen aus, Lederhosen aus
Zieht den Bayern die Lederhosen aus, Lederhosen aus, Lederhosen aus

Es ist jetzt 15:30,
und die Schiripfeife dröhnt.
Da hör ich wie von den Bayern,
der Meisterruf ertönt.
Doch dann nach 5 Minuten,
oh was für ein Graus,
da ziehn wir schon den Bayern
die Lederhosen aus.

Zieht den Bayern die Lederhosen aus, Lederhosen aus, Lederhosen aus
Zieht den Bayern die Lederhosen aus, Lederhosen aus, Lederhosen aus

Die letzten zehn Minuten,
jetzt müssen wir uns sputen.
Jeder Ball wird applaudiert,
und die Bayern ham schon lange resigniert.
Das Fazit dieses Samstags,
es ist schon kurios:
Die Bayern fahren wieder
ohne Lederhosen los.

Zieht den Bayern die Lederhosen aus, Lederhosen aus, Lederhosen aus
Zieht den Bayern die Lederhosen aus, Lederhosen aus, Lederhosen aus
Zieht den Bayern die Lederhosen aus, Lederhosen aus, Lederhosen aus
Zieht den Bayern die Lederhosen aus, Lederhosen aus, Lederhosen aus
...

2017-07-05 21:31 GMT+01:00 Matthias Müller :

> Hallo
>
> ich habe am Montag von Jessie auf Stretch aktualisiert.
> Kontact läuft soweit bis jetzt stabil. Übernahme der alten Mails hat auch
> sauber funktioniert. Meinen IMAP-Zugang fürs Versenden musste ich
> allerdings
> neu machen. Was da jetzt an den Einstellungen anders ist verstehe ich
> nicht.
> Aber das ist nicht das Problem, sondern:
> Kontact hat links (bei mir) am Rand die Ordnerübersicht. Als zusätzliche
> Spalten kann man die Anzahl der gelesenen, der ungelesenen und die Größe
> der
> Mails einstellen. Das habe ich gemacht, aber nach jedem Start von Kontact
> muss
> ich das Fenster mit der Ordnerübersicht breiter ziehen um die Spalten mit
> den
> Zahlen zu sehen.
> An welcher Stell muss ich hier schrauben, damit das dauerhaft so bleibt,
> wie
> ich es einstelle?
>
>
> System:
> Debian GNU/Linux 9.0 (stretch)
>
> Ich blick hier nicht durch, was ist das jetzt für eine KDE-Version?
> KDE Frameworks 5.28.0
> Qt 5.7.1 (kompiliert gegen 5.7.1)
> KDE Runtime (lt aptitude) 4.16.08.3-2
>
>
> --
> Mit freundlichen Grüßen
> Matthias Müller
> (Benutzer #439779 im Linux-Counter http://counter.li.org)
> PS: Bitte senden Sie als Antwort auf meine E-Mails reine Text-Nachrichten!

Re: PLEASE STOP YOUR MAILS

[Michael Fothergill]

On 8 July 2017 at 16:11,  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Sat, Jul 08, 2017 at 10:21:22AM -0400, Jason Wittlin-Cohen wrote:
> > If you want to unsubscribe, go here: https://lists.debian.org/
> debian-user/
> >
> > On Sat, Jul 8, 2017 at 2:55 AM, fisma2b  wrote:
> >
> > >
> > >
> > > I do not want to be in your mailing list anymore. Please remove my
> email
> > > from your list debian-user@lists.debian.org Stop your mails please
> Thanks
> > > again
>
> Hi, Jason, others: it's nice to give people a hint on how to
> unsubscribe, but after them having spammed the list with their
> request it doesn't help if you spam the list with the hints.
>
> I write to them directly, off list :-)
>

​I agree.  As soon as one off list email is sent to them we can then
collectively watch Engelbert Humperdinck singing Please Release Me on
youtube and forget about it.

Cheers

MF



>
> (Yes, I'm aware that they might get advice more than once.
> That's the downside).
>
> Cheers,
> - -- tomás
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iEYEARECAAYFAllg9hcACgkQBcgs9XrR2kZP+gCbBeXsJzUUfFuginciW/0JMLDg
> kOAAn0k1DGg1zxXXr6if5ZppDYnPfH1f
> =9/Ly
> -END PGP SIGNATURE-
>
>

Re: stop your mail

[Michael Fothergill]

On 8 July 2017 at 16:52, Fungi4All  wrote:

>
> From: scdbac...@gmx.net
>
> Hi,
> (Can real people be that stupid ? Is this the proof for
> brain damage caused by mobile phones ?)
>
>
> Look at how many people are NOT protesting the G20, or
> the earth's summit of earth destroyers.  This is how bad this
> epidemic of IQ drainage has gotten.  It is all sucked through
> FB and chasing pokemen.
>
> Maybe our list"s spam filter could give such phrases a spam rating
> sufficent to drop them if the sender is not subscribed ?
>
>
> How about an image file send with every subscription with a 18 digit
> random code you would have to type manually to activate?  Then use
> something like an encryption key to post to the list, so fake headers
> get blocked.
>
>
​How about voice encryption software that has recordings of each of us
singing our favourite Engelbert Humperdinck and/or Tom Jones songs...?

​ie a Mars Attack style defence mechanism where the would be hacker would
do insane trying to create the perfect rendition and upload it to the
list...

Cheers

MF

> Have a nice day :)
>
>
> What is even worse than smart-phoniasis is protesting in Hamburg
> with your digital identifying device in your pocket and wearing a hood.
> That scores lower in IQ than Trump.
>
> Have a great night
>

Re: Question on CVE-2017-5754 on Debian 8.9

[Michael Fothergill]

On 23 January 2018 at 21:16, Sven Hartge  wrote:

> Nicholas Geovanis  wrote:
>
> > I've installed the patch for CVE-2017-5754 as well as the microcode
> update:
>
> Well, Intel majorly fscked up their microcodes and strongly recommends
> to revert to an earlier BIOS/UEFI firmware (if possible) and also
> advised all vendors shipping microcode as a separate package (meaning
> VMware and all Linux vendors here) to revert to the version from
> November 2017, which so far all major Linux distributions have done.
>
> (Debian didn't even ship the update for Stable/Oldstable because the
> problems where already showing two weeks ago.)
>
> So, right now, unless you have the latest bleeding edge kernel, compiled
> with a repoline-aware pre-release GCC, you will be vulnerable for
> CVE-2017-5753 (Spectre#1) and CVE-2017-5715 (Spectre#2) for quite some
> time.
>
>
​Hi there,  I am running kernel 4.14.14 under gentoo testing on an AMD
kaveri box.

The version of GCC I am using is 7.2.  Whether that means the reptoline
patch is working for me I am not quite sure but it could be I guess.

Someone who is smarter than the average bear has written a patch for the
spectre problem with no performance penalty:

https://www.neowin.net/news/retpoline-patch-coming-to-linux-49-and-linux-414

​I am not sure if you can do this as debian testing or experimental.

Cheers

Michael Fothergill
​


> > # uname -a
> > Linux ftp51 3.16.0-5-amd64 #1 SMP Debian 3.16.51-3+deb8u1 (2018-01-08)
> > x86_64 GNU/Linux
> > # dmesg | grep isolation
> > [0.00] Kernel/User page tables isolation: enabled
>
> > And yet, the widely-recommended test script at
> > https://raw.githubusercontent.com/speed47/spectre-meltdown-
> checker/master/spectre-meltdown-checker.sh
>
> Did you run the script as root? Did you use the most recent version of
> it? It gets developed quite rapidly, maybe you got a version which was
> not correctly functioning at that moment, giving that you download the
> script from the master-branch instead of one of the tagged releases.
>
> S°
>
> --
> Sigmentation fault. Core dumped.
>
>

Re: Question on CVE-2017-5754 on Debian 8.9

[Michael Fothergill]

>>
> ​Hi there,  I am running kernel 4.14.14 under gentoo testing on an AMD
> kaveri box.
>
> The version of GCC I am using is 7.2.  Whether that means the reptoline
> patch is working for me I am not quite sure but it could be I guess.
>
> Someone who is smarter than the average bear has written a patch for the
> spectre problem with no performance penalty:
>
> https://www.neowin.net/news/retpoline-patch-coming-to-
> linux-49-and-linux-414
>
> ​I am not sure if you can do this as debian testing or experimental.
>
> Cheers
>
> Michael Fothergill
>

​You can compile the kernel in debian:​

> ​https://www.debian.org/releases/jessie/i386/ch08s06.html.en
>

​There is also a debian page on gcc7
​
https://wiki.debian.org/GCC7

​If I ask the gentoo folks they will tell me if the KPTI and retpoline
patches are turned on automatically in kernel 4.14.14
or if you have to set a specific flag when you run make menuconfig (runs in
Debian too); then if GCC7 is new enough for this
you are good to go..

Cheers

MF

Re: Question on CVE-2017-5754 on Debian 8.9

[Michael Fothergill]

>
> The neowin link above has a link to a Phoronix article[1], which
> suggests you need GCC 8.0, or maybe 7.3 if a backport succeeds. That was
> 9 days ago, of course ... Stretch only has 6.3, and even sid only has
> 7.2, so I don't see it hitting debian soon.
>
> Richard
>
> [1]
> https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.
> 9-4.14-Retpoline


​Some new patches are coming soon:

https://www.phoronix.com/scan.php?page=news_item&px=Spectre-Variant-One-Linux-4.16

​https://www.phoronix.com/scan.php?page=news_item&px=LLVM-Retpoline-Added

I have posted a query on the gentoo forum asking if I have a recent enough
version of gcc etc for the retpoline.

There is a test program you can install and run and it will tell you if
both the meltdown and spectre patched are installed which I will try out.

Looks like your all going to have to run the latest kernels(J)

Regards

MF

Re: Question on CVE-2017-5754 on Debian 8.9

[Michael Fothergill]

On 24 January 2018 at 10:53, Michael Fothergill <
michael.fotherg...@gmail.com> wrote:

>
>
>
>>
>> The neowin link above has a link to a Phoronix article[1], which
>> suggests you need GCC 8.0, or maybe 7.3 if a backport succeeds. That was
>> 9 days ago, of course ... Stretch only has 6.3, and even sid only has
>> 7.2, so I don't see it hitting debian soon.
>>
>> Richard
>>
>> [1]
>> https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.
>> 9-4.14-Retpoline
>
>
> ​Some new patches are coming soon:
>
> https://www.phoronix.com/scan.php?page=news_item&px=Spectre-
> Variant-One-Linux-4.16
>
> ​https://www.phoronix.com/scan.php?page=news_item&px=LLVM-Retpoline-Added
>
> I have posted a query on the gentoo forum asking if I have a recent enough
> version of gcc etc for the retpoline.
>
> There is a test program you can install and run and it will tell you if
> both the meltdown and spectre patched are installed which I will try out.
>
> Looks like your all going to have to run the latest kernels(J)
>
> Regards
>
> MF
>


​PS I installed the spectre meltdown checker and ran it:djt
/home/mikef/spectre-meltdown-checker # ./spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.32

Checking for vulnerabilities on current system
Kernel is Linux 4.14.14-gentoo #1 SMP Tue Jan 23 13:06:23 GMT 2018 x86_64
CPU is AMD A10-7850K Radeon R7, 12 Compute Cores 4C+8G

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface:  NO  (kernel confirms your
system is vulnerable)
> STATUS:  VULNERABLE  (Vulnerable)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface:  NO  (kernel confirms your
system is vulnerable)
* Mitigation 1
  * Hardware support (CPU microcode)
* Indirect Branch Restricted Speculation (IBRS)
  * SPEC_CTRL MSR is available:  NO
  * CPU indicates IBRS capability:  NO
* Indirect Branch Prediction Barrier (IBPB)
  * PRED_CMD MSR is available:  NO
  * CPU indicates IBPB capability:  NO
  * Kernel is compiled with IBRS/IBPB support:  NO
  * Currently enabled features
* IBRS enabled for Kernel space:  NO
* IBRS enabled for User space:  NO
* IBPB enabled:  NO
* Mitigation 2
  * Kernel compiled with retpoline option:  YES
  * Kernel compiled with a retpoline-aware compiler:  NO  (kernel reports
minimal retpoline compilation)
  * Retpoline enabled:  YES
> STATUS:  VULNERABLE  (Vulnerable: Minimal AMD ASM retpoline)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface:  YES  (kernel confirms that
your CPU is unaffected)
* Kernel supports Page Table Isolation (PTI):  YES
* PTI enabled and active:  NO
* Running under Xen PV (64 bits):  NO
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not
vulnerable)

A false sense of security is worse than no security at all, see --disclaimer
djt /home/mikef/spectre-meltdown-checker #

ie it's there but GCC 7.2 can't install it.

If you look at the discussion here:

https://forums.gentoo.org/viewtopic-p-8174746.html#8174746

you will see that I need to install gcc 7.3.0rc1

time to compile your own kernels...

Cheers

MF






​




>
>
>
>
>
>
>
>
>

Re: Question on CVE-2017-5754 on Debian 8.9

[Michael Fothergill]

On 24 January 2018 at 11:21, Michael Fothergill <
michael.fotherg...@gmail.com> wrote:

>
>
> On 24 January 2018 at 10:53, Michael Fothergill <
> michael.fotherg...@gmail.com> wrote:
>
>>
>>
>>
>>>
>>> The neowin link above has a link to a Phoronix article[1], which
>>> suggests you need GCC 8.0, or maybe 7.3 if a backport succeeds. That was
>>> 9 days ago, of course ... Stretch only has 6.3, and even sid only has
>>> 7.2, so I don't see it hitting debian soon.
>>>
>>> Richard
>>>
>>> [1]
>>> https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.
>>> 9-4.14-Retpoline
>>
>>
>> ​Some new patches are coming soon:
>>
>> https://www.phoronix.com/scan.php?page=news_item&px=Spectre-
>> Variant-One-Linux-4.16
>>
>> ​https://www.phoronix.com/scan.php?page=news_item&px=LLVM-Retpoline-Added
>>
>> I have posted a query on the gentoo forum asking if I have a recent
>> enough version of gcc etc for the retpoline.
>>
>> There is a test program you can install and run and it will tell you if
>> both the meltdown and spectre patched are installed which I will try out.
>>
>> Looks like your all going to have to run the latest kernels(J)
>>
>> Regards
>>
>> MF
>>
>
>
> ​PS I installed the spectre meltdown checker and ran it:djt
> /home/mikef/spectre-meltdown-checker # ./spectre-meltdown-checker.sh
> Spectre and Meltdown mitigation detection tool v0.32
>
> Checking for vulnerabilities on current system
> Kernel is Linux 4.14.14-gentoo #1 SMP Tue Jan 23 13:06:23 GMT 2018 x86_64
> CPU is AMD A10-7850K Radeon R7, 12 Compute Cores 4C+8G
>
> CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
> * Mitigated according to the /sys interface:  NO  (kernel confirms your
> system is vulnerable)
> > STATUS:  VULNERABLE  (Vulnerable)
>
> CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
> * Mitigated according to the /sys interface:  NO  (kernel confirms your
> system is vulnerable)
> * Mitigation 1
>   * Hardware support (CPU microcode)
> * Indirect Branch Restricted Speculation (IBRS)
>   * SPEC_CTRL MSR is available:  NO
>   * CPU indicates IBRS capability:  NO
> * Indirect Branch Prediction Barrier (IBPB)
>   * PRED_CMD MSR is available:  NO
>   * CPU indicates IBPB capability:  NO
>   * Kernel is compiled with IBRS/IBPB support:  NO
>   * Currently enabled features
> * IBRS enabled for Kernel space:  NO
> * IBRS enabled for User space:  NO
> * IBPB enabled:  NO
> * Mitigation 2
>   * Kernel compiled with retpoline option:  YES
>   * Kernel compiled with a retpoline-aware compiler:  NO  (kernel reports
> minimal retpoline compilation)
>   * Retpoline enabled:  YES
> > STATUS:  VULNERABLE  (Vulnerable: Minimal AMD ASM retpoline)
>
> CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
> * Mitigated according to the /sys interface:  YES  (kernel confirms that
> your CPU is unaffected)
> * Kernel supports Page Table Isolation (PTI):  YES
> * PTI enabled and active:  NO
> * Running under Xen PV (64 bits):  NO
> > STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not
> vulnerable)
>
> A false sense of security is worse than no security at all, see
> --disclaimer
> djt /home/mikef/spectre-meltdown-checker #
>
> ie it's there but GCC 7.2 can't install it.
>
> If you look at the discussion here:
>
> https://forums.gentoo.org/viewtopic-p-8174746.html#8174746
>
> you will see that I need to install gcc 7.3.0rc1
>
> time to compile your own kernels...
>
> Cheers
>
> MF
>

​PPS

GCC 7.3 is coming soon:

​https://www.phoronix.com/scan.php?page=news_item&px=GCC-7.3-In-January

so, problem solved.

>
>
>
>
>
>
> ​
>
>
>
>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>

Re: Question on CVE-2017-5754 on Debian 8.9

[Michael Fothergill]

On 24 January 2018 at 11:52, Michael Fothergill <
michael.fotherg...@gmail.com> wrote:

>
>
> On 24 January 2018 at 11:21, Michael Fothergill <
> michael.fotherg...@gmail.com> wrote:
>
>>
>>
>> On 24 January 2018 at 10:53, Michael Fothergill <
>> michael.fotherg...@gmail.com> wrote:
>>
>>>
>>>
>>>
>>>>
>>>> The neowin link above has a link to a Phoronix article[1], which
>>>> suggests you need GCC 8.0, or maybe 7.3 if a backport succeeds. That was
>>>> 9 days ago, of course ... Stretch only has 6.3, and even sid only has
>>>> 7.2, so I don't see it hitting debian soon.
>>>>
>>>> Richard
>>>>
>>>> [1]
>>>> https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.
>>>> 9-4.14-Retpoline
>>>
>>>
>>> ​Some new patches are coming soon:
>>>
>>> https://www.phoronix.com/scan.php?page=news_item&px=Spectre-
>>> Variant-One-Linux-4.16
>>>
>>> ​https://www.phoronix.com/scan.php?page=news_item&px=LLVM-Re
>>> tpoline-Added
>>>
>>> I have posted a query on the gentoo forum asking if I have a recent
>>> enough version of gcc etc for the retpoline.
>>>
>>> There is a test program you can install and run and it will tell you if
>>> both the meltdown and spectre patched are installed which I will try out.
>>>
>>> Looks like your all going to have to run the latest kernels(J)
>>>
>>> Regards
>>>
>>> MF
>>>
>>
>>
>> ​PS I installed the spectre meltdown checker and ran it:djt
>> /home/mikef/spectre-meltdown-checker # ./spectre-meltdown-checker.sh
>> Spectre and Meltdown mitigation detection tool v0.32
>>
>> Checking for vulnerabilities on current system
>> Kernel is Linux 4.14.14-gentoo #1 SMP Tue Jan 23 13:06:23 GMT 2018 x86_64
>> CPU is AMD A10-7850K Radeon R7, 12 Compute Cores 4C+8G
>>
>> CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
>> * Mitigated according to the /sys interface:  NO  (kernel confirms your
>> system is vulnerable)
>> > STATUS:  VULNERABLE  (Vulnerable)
>>
>> CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
>> * Mitigated according to the /sys interface:  NO  (kernel confirms your
>> system is vulnerable)
>> * Mitigation 1
>>   * Hardware support (CPU microcode)
>> * Indirect Branch Restricted Speculation (IBRS)
>>   * SPEC_CTRL MSR is available:  NO
>>   * CPU indicates IBRS capability:  NO
>> * Indirect Branch Prediction Barrier (IBPB)
>>   * PRED_CMD MSR is available:  NO
>>   * CPU indicates IBPB capability:  NO
>>   * Kernel is compiled with IBRS/IBPB support:  NO
>>   * Currently enabled features
>> * IBRS enabled for Kernel space:  NO
>> * IBRS enabled for User space:  NO
>> * IBPB enabled:  NO
>> * Mitigation 2
>>   * Kernel compiled with retpoline option:  YES
>>   * Kernel compiled with a retpoline-aware compiler:  NO  (kernel reports
>> minimal retpoline compilation)
>>   * Retpoline enabled:  YES
>> > STATUS:  VULNERABLE  (Vulnerable: Minimal AMD ASM retpoline)
>>
>> CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
>> * Mitigated according to the /sys interface:  YES  (kernel confirms that
>> your CPU is unaffected)
>> * Kernel supports Page Table Isolation (PTI):  YES
>> * PTI enabled and active:  NO
>> * Running under Xen PV (64 bits):  NO
>> > STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as
>> not vulnerable)
>>
>> A false sense of security is worse than no security at all, see
>> --disclaimer
>> djt /home/mikef/spectre-meltdown-checker #
>>
>> ie it's there but GCC 7.2 can't install it.
>>
>> If you look at the discussion here:
>>
>> https://forums.gentoo.org/viewtopic-p-8174746.html#8174746
>>
>> you will see that I need to install gcc 7.3.0rc1
>>
>> time to compile your own kernels...
>>
>> Cheers
>>
>> MF
>>
>
> ​PPS
>
> GCC 7.3 is coming soon:
>
> ​https://www.phoronix.com/scan.php?page=news_item&px=GCC-7.3-In-January
>
> so, problem solved
>

​The link within the above one: ​
https://gcc.gnu.org/ml/gcc/2018-01/msg00148.html
​also has a link to the ftp download for the release candidate version of
gcc 7.3 ie 7.3.0rc1 which does actually work for spectre and retpoline.

So while waiting for the official release of 7.3. we could do a manual
installation of gcc 7.3.0 rc1 from the tar file and somehow uninstall the
current gcc deb file in stretch
and plumb in the manually compiled 7.3 rc1 edition into the debian install.

Then we can install the 4.14.14 kernel.

A doddle.



​






>
>>
>>
>>
>>
>> ​
>>
>>
>>
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>

Re: Question on CVE-2017-5754 on Debian 8.9

[Michael Fothergill]

On 24 January 2018 at 12:58, Sven Hartge  wrote:

> Michael Fothergill  wrote:
>
> > The link within the above one:
> > https://gcc.gnu.org/ml/gcc/2018-01/msg00148.html
> > also has a link to the ftp download for the release candidate version of
> > gcc 7.3 ie 7.3.0rc1 which does actually work for spectre and retpoline.
>
> Debian Sid got gcc-7.3.0rc2 last night, the package is still named gcc-7
> (7.2.0-20) though.
>

​Does that mean that if you upgrade to sid and installed gcc 7.2.0 you
would actually get 7.3.0rc2 in practice?

If so then you would then go ahead and manually compile kernel 4.14.14 and
you would be straight.

Cheers

MF​



>
> S°
>
> --
> Sigmentation fault. Core dumped.
>
>

Re: Question on CVE-2017-5754 on Debian 8.9

[Michael Fothergill]

On 24 January 2018 at 14:11, Vincent Lefevre  wrote:

> On 2018-01-24 14:44:18 +0100, Sven Hartge wrote:
> > Michael Fothergill  wrote:
> > > On 24 January 2018 at 12:58, Sven Hartge  wrote:
> >
> > >> Michael Fothergill  wrote:
> >
> > >> > The link within the above one:
> > >>> https://gcc.gnu.org/ml/gcc/2018-01/msg00148.html
> > >>> also has a link to the ftp download for the release candidate
> version of
> > >>> gcc 7.3 ie 7.3.0rc1 which does actually work for spectre and
> retpoline.
> >
> > >> Debian Sid got gcc-7.3.0rc2 last night, the package is still named
> gcc-7
> > >> (7.2.0-20) though.
> >
> > > Does that mean that if you upgrade to sid and installed gcc 7.2.0 you
> > > would actually get 7.3.0rc2 in practice?
> >
> > Unless I interpret the changelog wrong: yes.
>
> But the changelogs don't mention anything about Spectre and retpoline.
>

​It's OK.  As long as you really do end up installing gcc 7.3.0 rc2 we know
it can handle the compilation of kernel 4.14.14 correctly to
make the KPTI and retpoline patches work...

So the changelog doesn't matter.

Cheers

MF​



>
> --
> Vincent Lefèvre  - Web: <https://www.vinc17.net/>
> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
>
>

Re: Question on CVE-2017-5754 on Debian 8.9

[Michael Fothergill]

On 24 January 2018 at 14:15, Michael Fothergill <
michael.fotherg...@gmail.com> wrote:

>
>
> On 24 January 2018 at 14:11, Vincent Lefevre  wrote:
>
>> On 2018-01-24 14:44:18 +0100, Sven Hartge wrote:
>> > Michael Fothergill  wrote:
>> > > On 24 January 2018 at 12:58, Sven Hartge  wrote:
>> >
>> > >> Michael Fothergill  wrote:
>> >
>> > >> > The link within the above one:
>> > >>> https://gcc.gnu.org/ml/gcc/2018-01/msg00148.html
>> > >>> also has a link to the ftp download for the release candidate
>> version of
>> > >>> gcc 7.3 ie 7.3.0rc1 which does actually work for spectre and
>> retpoline.
>> >
>> > >> Debian Sid got gcc-7.3.0rc2 last night, the package is still named
>> gcc-7
>> > >> (7.2.0-20) though.
>> >
>> > > Does that mean that if you upgrade to sid and installed gcc 7.2.0 you
>> > > would actually get 7.3.0rc2 in practice?
>> >
>> > Unless I interpret the changelog wrong: yes.
>>
>

​I have found a kernel image file here:

​https://packages.debian.org/experimental/linux-image-4.15.0-rc8-amd64

I think this will likely work OK with KPTI and retpoline.

It's in debian experimental.

If you can be sid and experimental together then I guess you can have gcc
7.3 rc1 or 2 (or whatever it is) installed and then
install the image as a kernel upgrade not a kernel compilation:

Something like this:

 # cat >> /etc/apt/preferences << EOF Package: * Pin: release
o=Debian,a=experimental Pin-Priority: 102 EOF # apt-cache policy   #
shows/verifies the current preferences # echo "deb
http://deb.debian.org/debian experimental main" >>
/etc/apt/sources.list # apt-get update # apt-get -t experimental
install linux-image-3.10-rc5-686-pae




Except here you would do:

# apt-get -t experimental install linux-image-4.15.0-rc8-amd64

Then I would have thought KPTI and retpoline would be installed in a
relatively painless way if you don't mind running as sid.

Cheers

MF









>
>> But the changelogs don't mention anything about Spectre and retpoline.
>>
>
> ​It's OK.  As long as you really do end up installing gcc 7.3.0 rc2 we
> know it can handle the compilation of kernel 4.14.14 correctly to
> make the KPTI and retpoline patches work...
>
> So the changelog doesn't matter.
>
> Cheers
>
> MF​
>
>
>
>>
>> --
>> Vincent Lefèvre  - Web: <https://www.vinc17.net/>
>> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
>> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
>>
>>
>

Re: Question on CVE-2017-5754 on Debian 8.9

[Michael Fothergill]

On 24 January 2018 at 15:49, Michael Fothergill <
michael.fotherg...@gmail.com> wrote:

>
>
> On 24 January 2018 at 14:15, Michael Fothergill <
> michael.fotherg...@gmail.com> wrote:
>
>>
>>
>> On 24 January 2018 at 14:11, Vincent Lefevre  wrote:
>>
>>> On 2018-01-24 14:44:18 +0100, Sven Hartge wrote:
>>> > Michael Fothergill  wrote:
>>> > > On 24 January 2018 at 12:58, Sven Hartge  wrote:
>>> >
>>> > >> Michael Fothergill  wrote:
>>> >
>>> > >> > The link within the above one:
>>> > >>> https://gcc.gnu.org/ml/gcc/2018-01/msg00148.html
>>> > >>> also has a link to the ftp download for the release candidate
>>> version of
>>> > >>> gcc 7.3 ie 7.3.0rc1 which does actually work for spectre and
>>> retpoline.
>>> >
>>> > >> Debian Sid got gcc-7.3.0rc2 last night, the package is still named
>>> gcc-7
>>> > >> (7.2.0-20) though.
>>> >
>>> > > Does that mean that if you upgrade to sid and installed gcc 7.2.0 you
>>> > > would actually get 7.3.0rc2 in practice?
>>> >
>>> > Unless I interpret the changelog wrong: yes.
>>>
>>
>
> ​I have found a kernel image file here:
>
> ​https://packages.debian.org/experimental/linux-image-4.15.0-rc8-amd64
>
> I think this will likely work OK with KPTI and retpoline.
>
> It's in debian experimental.
>
> If you can be sid and experimental together then I guess you can have gcc
> 7.3 rc1 or 2 (or whatever it is) installed and then
> install the image as a kernel upgrade not a kernel compilation:
>
> Something like this:
>
>  # cat >> /etc/apt/preferences << EOF Package: * Pin: release 
> o=Debian,a=experimental Pin-Priority: 102 EOF # apt-cache policy   # 
> shows/verifies the current preferences # echo "deb 
> http://deb.debian.org/debian experimental main" >> /etc/apt/sources.list # 
> apt-get update # apt-get -t experimental install linux-image-3.10-rc5-686-pae
>
>
>
>
> Except here you would do:
>
> # apt-get -t experimental install linux-image-4.15.0-rc8-amd64
>
> Then I would have thought KPTI and retpoline would be installed in a
> relatively painless way if you don't mind running as sid.
>
> Cheers
>
> MF
>

​Wait a minute.  If the linux image kernel is a binary ie compiled then as
long as it was compiled using a gcc compiler v 7.3 or greater
then the retpoline and KPTI would correctly installed by default.

So, if my understanding is correct then would that not mean you would not
need to have v 7.3 of gcc installed locally so you would
not need to become sid?

Just a thought.

MF





​



>
>
>
>
>
>
>
>
>
>>
>>> But the changelogs don't mention anything about Spectre and retpoline.
>>>
>>
>> ​It's OK.  As long as you really do end up installing gcc 7.3.0 rc2 we
>> know it can handle the compilation of kernel 4.14.14 correctly to
>> make the KPTI and retpoline patches work...
>>
>> So the changelog doesn't matter.
>>
>> Cheers
>>
>> MF​
>>
>>
>>
>>>
>>> --
>>> Vincent Lefèvre  - Web: <https://www.vinc17.net/>
>>> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
>>> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
>>>
>>>
>>
>

Re: Question on CVE-2017-5754 on Debian 8.9

[Michael Fothergill]

On 24 January 2018 at 16:19, Greg Wooledge  wrote:

> On Wed, Jan 24, 2018 at 03:49:08PM +0000, Michael Fothergill wrote:
> > If you can be sid and experimental together then I guess [...]
>
> Experimental is not a release.  You can't "be experimental".  It is
> merely a place where individual packages are uploaded, when they are
> considered "not ready to be in unstable yet".
>
> Typically the package maintainer EXPECTS these packages to have bugs,
> and wants focused help from people who are familiar with the package
> to find and squish them.  Or, the package may be uploaded in a "known
> broken" condition because it could still be useful in highly specialized
> circumstances, where the new features outweigh the known bugs.
>
> The packages in experimental do NOT automatically migrate into unstable
> or testing.  They are not part of the normal package lifecycle.
>
> To use a package from experimental, you must download it directly, and
> install it directly.  You don't use apt or its cousins, unless it's
> to backfill dependencies (apt-get -f install) from your actual release.
>

​I fired up Debian stretch here and ran the following:​


​r​
oot@mikef-PC:/etc/apt# apt-get update
Ign:1 http://ftp.uk.debian.org/debian stretch InRelease
Hit:2 http://ftp.uk.debian.org/debian stretch Release
Hit:3 http://security.debian.org stretch/updates InRelease
Reading package lists... Done
root@mikef-PC:/etc/apt# apt-get -t experimental install
linux-headers-4.15.0-rc8-all-amd64
Reading package lists... Done

​and got the following error:​


E: The value 'experimental' is invalid for APT::Default-Release as such a
release is not available in the sources

​Mysources file looks like this:​


root@mikef-PC:/etc/apt# more sources.list
#



## Debian Main Repos
deb http://ftp.uk.debian.org/debian/ stretch main experimental contrib
non-free

## Debian Update Repos
deb http://security.debian.org/ stretch/updates main contrib non-free

deb-src http://security.debian.org/ stretch/updates main contrib non-free


root@mikef-PC:/etc/apt#



Is the error caused by me trying to run apt at all here ie I should use
some other command to install the linux image file?

Comments appreciated.

Michael Fothergill​

Re: Question on CVE-2017-5754 on Debian 8.9

[Michael Fothergill]

On 24 January 2018 at 16:19, Greg Wooledge  wrote:

> On Wed, Jan 24, 2018 at 03:49:08PM +0000, Michael Fothergill wrote:
> > If you can be sid and experimental together then I guess [...]
>
> Experimental is not a release.  You can't "be experimental".  It is
> merely a place where individual packages are uploaded, when they are
> considered "not ready to be in unstable yet".
>
> Typically the package maintainer EXPECTS these packages to have bugs,
> and wants focused help from people who are familiar with the package
> to find and squish them.  Or, the package may be uploaded in a "known
> broken" condition because it could still be useful in highly specialized
> circumstances, where the new features outweigh the known bugs.
>
> The packages in experimental do NOT automatically migrate into unstable
> or testing.  They are not part of the normal package lifecycle.
>
> To use a package from experimental, you must download it directly, and
> install it directly.  You don't use apt or its cousins, unless it's
> to backfill dependencies (apt-get -f install) from your actual release.
>

​Does that mean you use dpkg -i to ibstall it then?

Cheers

MF​

Re: Question on CVE-2017-5754 on Debian 8.9

[Michael Fothergill]

On 24 January 2018 at 17:38, Greg Wooledge  wrote:

> On Wed, Jan 24, 2018 at 04:51:35PM +0000, Michael Fothergill wrote:
> > root@mikef-PC:/etc/apt# apt-get -t experimental install
> > linux-headers-4.15.0-rc8-all-amd64
> > Reading package lists... Done
> >
> > ​and got the following error:​
> >
> >
> > E: The value 'experimental' is invalid for APT::Default-Release as such a
> > release is not available in the sources
>
> Just get the package(s) directly from
> http://packages.debian.org/experimental/


​and then use dpkg -i or abracadbra?

Cheers

MF

​

Re: Question on CVE-2017-5754 on Debian 8.9

[Michael Fothergill]

On 24 January 2018 at 17:38, Greg Wooledge  wrote:

> On Wed, Jan 24, 2018 at 04:51:35PM +0000, Michael Fothergill wrote:
> > root@mikef-PC:/etc/apt# apt-get -t experimental install
> > linux-headers-4.15.0-rc8-all-amd64
> > Reading package lists... Done
> >
> > ​and got the following error:​
> >
> >
> > E: The value 'experimental' is invalid for APT::Default-Release as such a
> > release is not available in the sources
>
> Just get the package(s) directly from
> http://packages.debian.org/experimental/


​I did it and installed it with dpkg -i


/home/mikef/Downloads
mikef@mikef-PC:~/Downloads$ su
Password:
root@mikef-PC:/home/mikef/Downloads# ls
05_Debeche_EnzymeMicrobTech.pdf
climostat-slides-2017.pptx
GB2506880A.pdf
Gentoo-Linux-livedvd-amd64-multilib-20160704
Gmail - New Substances Notification.pdf
Gmail-New-Substances-Notification.pdf
linux-image-4.15.0-rc8-amd64_4.15~rc8-1~exp1_amd64.deb
python-pyqtgraph_0.10.0-1_all.deb
root@mikef-PC:/home/mikef/Downloads# dpkg -i
linux-image-4.15.0-rc8-amd64_4.15~rc8-1~exp1_amd64.deb
(Reading database ... 222960 files and directories currently installed.)
Preparing to unpack linux-image-4.15.0-rc8-amd64_4.15~rc8-1~exp1_amd64.deb
...
Unpacking linux-image-4.15.0-rc8-amd64 (4.15~rc8-1~exp1) over
(4.15~rc8-1~exp1) ...
Setting up linux-image-4.15.0-rc8-amd64 (4.15~rc8-1~exp1) ...
/etc/kernel/postinst.d/dkms:
Error! Your kernel headers for kernel 4.15.0-rc8-amd64 cannot be found.
Please install the linux-headers-4.15.0-rc8-amd64 package,
or use the --kernelsourcedir option to tell DKMS where it's located
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-4.15.0-rc8-amd64
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8107e-2.fw for module
r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8107e-1.fw for module
r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168h-2.fw for module
r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168h-1.fw for module
r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168g-3.fw for module
r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168g-2.fw for module
r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8106e-2.fw for module
r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8106e-1.fw for module
r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8411-2.fw for module
r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8411-1.fw for module
r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8402-1.fw for module
r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168f-2.fw for module
r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168f-1.fw for module
r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8105e-1.fw for module
r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168e-3.fw for module
r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168e-2.fw for module
r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168e-1.fw for module
r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168d-2.fw for module
r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168d-1.fw for module
r8169
W: Possible missing firmware /lib/firmware/radeon/banks_k_2_smc.bin for
module radeon
/etc/kernel/postinst.d/zz-update-grub:
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-4.15.0-rc8-amd64
Found initrd image: /boot/initrd.img-4.15.0-rc8-amd64
Found linux image: /boot/vmlinuz-4.9.0-4-amd64
Found initrd image: /boot/initrd.img-4.9.0-4-amd64
Found linux image: /boot/vmlinuz-4.9.0-3-amd64
Found initrd image: /boot/initrd.img-4.9.0-3-amd64
Found linux image: /boot/vmlinuz-3.16.0-4-amd64
Found initrd image: /boot/initrd.img-3.16.0-4-amd64
Found memtest86+ image: /boot/memtest86+.bin
Found memtest86+ multiboot image: /boot/memtest86+_multiboot.bin
Found Windows 10 on /dev/sda1
Found Windows 10 on /dev/sda2
Found Gentoo/Linux on /dev/sda8
done
root@mikef-PC:/home/mikef/Downloads#


There is a gripe in there about the linux headers file not being installed
for it.

There is a linux header file on the experimental web page.

I think I need to install that as well.

Cheers

MF








​

Re: Question on CVE-2017-5754 on Debian 8.9

[Michael Fothergill]

On 24 January 2018 at 18:00, Michael Fothergill <
michael.fotherg...@gmail.com> wrote:

>
>
>
>
>
>
> W: Possible missing firmware /lib/firmware/rtl_nic/rtl8105e-1.fw for
> module r8169
>
>
> There is a gripe in there about the linux headers file not being installed
> for it.
>
> There is a linux header file on the experimental web page.
>
> I think I need to install that as well.
>

​I tried installing the headers file and it says I have dependency
problems:​


root@mikef-PC:/home/mikef/Downloads# dpkg -i
linux-headers-4.15.0-rc8-all-amd64_4.15~rc8-1~exp1_amd64.deb
Selecting previously unselected package linux-headers-4.15.0-rc8-all-amd64.
(Reading database ... 222960 files and directories currently installed.)
Preparing to unpack
linux-headers-4.15.0-rc8-all-amd64_4.15~rc8-1~exp1_amd64.deb ...
Unpacking linux-headers-4.15.0-rc8-all-amd64 (4.15~rc8-1~exp1) ...
dpkg: dependency problems prevent configuration of
linux-headers-4.15.0-rc8-all-amd64:
 linux-headers-4.15.0-rc8-all-amd64 depends on
linux-headers-4.15.0-rc8-amd64 (= 4.15~rc8-1~exp1); however:
  Package linux-headers-4.15.0-rc8-amd64 is not installed.

​It almost sounds like some kind of rehab is required here.

Comments appreciated.

Cheers

MF​




>
> Cheers
>
> MF
>
>
>
>
>
>
>
>
> ​
>
>
>

Re: Question on CVE-2017-5754 on Debian 8.9

[Michael Fothergill]

On 24 January 2018 at 18:12, Michael Fothergill <
michael.fotherg...@gmail.com> wrote:

>
>
> On 24 January 2018 at 18:00, Michael Fothergill <
> michael.fotherg...@gmail.com> wrote:
>
>>
>>
>>
>>
>>
>>
>> W: Possible missing firmware /lib/firmware/rtl_nic/rtl8105e-1.fw for
>> module r8169
>>
>>
>> There is a gripe in there about the linux headers file not being
>> installed for it.
>>
>> There is a linux header file on the experimental web page.
>>
>> I think I need to install that as well.
>>
>
> ​I tried installing the headers file and it says I have dependency
> problems:​
>
>
> root@mikef-PC:/home/mikef/Downloads# dpkg -i linux-headers-4.15.0-rc8-all-
> amd64_4.15~rc8-1~exp1_amd64.deb
> Selecting previously unselected package linux-headers-4.15.0-rc8-all-
> amd64.
> (Reading database ... 222960 files and directories currently installed.)
> Preparing to unpack linux-headers-4.15.0-rc8-all-
> amd64_4.15~rc8-1~exp1_amd64.deb ...
> Unpacking linux-headers-4.15.0-rc8-all-amd64 (4.15~rc8-1~exp1) ...
> dpkg: dependency problems prevent configuration of
> linux-headers-4.15.0-rc8-all-amd64:
>  linux-headers-4.15.0-rc8-all-amd64 depends on
> linux-headers-4.15.0-rc8-amd64 (= 4.15~rc8-1~exp1); however:
>   Package linux-headers-4.15.0-rc8-amd64 is not installed.
>
> ​It almost sounds like some kind of rehab is required here.
>
> Comments appreciated.
>
> Cheers
>
> MF​
>

​It is easier to do this stuff in Gentoo I think...

It does take a long time to learn but it is worth it.

When the gcc 7.3 build comes out I will upgrade and then use it to
recompile the 4.14.14 kernel.

And it will work.

I will also get the kernels after that and install them in a flash.

Cheers

MF



​



>
>
>
>
>>
>> Cheers
>>
>> MF
>>
>>
>>
>>
>>
>>
>>
>>
>> ​
>>
>>
>>
>

Re: Question on CVE-2017-5754 on Debian 8.9

[Michael Fothergill]

On 24 January 2018 at 22:32, Michael Lange  wrote:

> Hi,
>
> On Wed, 24 Jan 2018 20:07:07 +
> Michael Fothergill  wrote:
>
> (...)
> > > ​I tried installing the headers file and it says I have dependency
> > > problems:​
> > >
> > >
> > > root@mikef-PC:/home/mikef/Downloads# dpkg -i
> > > linux-headers-4.15.0-rc8-all- amd64_4.15~rc8-1~exp1_amd64.deb
> > > Selecting previously unselected package linux-headers-4.15.0-rc8-all-
> > > amd64.
> > > (Reading database ... 222960 files and directories currently
> > > installed.) Preparing to unpack linux-headers-4.15.0-rc8-all-
> > > amd64_4.15~rc8-1~exp1_amd64.deb ...
> > > Unpacking linux-headers-4.15.0-rc8-all-amd64 (4.15~rc8-1~exp1) ...
> > > dpkg: dependency problems prevent configuration of
> > > linux-headers-4.15.0-rc8-all-amd64:
> > >  linux-headers-4.15.0-rc8-all-amd64 depends on
> > > linux-headers-4.15.0-rc8-amd64 (= 4.15~rc8-1~exp1); however:
> > >   Package linux-headers-4.15.0-rc8-amd64 is not installed.
> > >
> > > ​It almost sounds like some kind of rehab is required here.
>
> no, I don't think so ;)
> You just need to do what the error message from dpkg tells you and
> download the linux-headers-4.15.0-rc8-amd64 package from
> https://packages.debian.org/experimental/linux-headers-4.15.0-rc8-amd64
> and install it along with
> linux-headers-4.15.0-rc8-all-amd64_4.15~rc8-1~exp1_amd64.deb
>
> Maybe you stumbled over the similarity between those two packages' names?
>


​OK,  I installed buster and the other dependencies and gcc 7.2.

When I upgraded then kernel 4.15.0 was installed.

I ran the patch checker:

root@mikef-PC:/home/mikef/spectre-meltdown-checker#
./spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.32

Checking for vulnerabilities on current system
Kernel is Linux 4.15.0-rc8-amd64 #1 SMP Debian 4.15~rc8-1~exp1 (2018-01-15)
x86_64
CPU is AMD A10-7850K Radeon R7, 12 Compute Cores 4C+8G

Hardware check
* Hardware support (CPU microcode) for mitigation techniques
  * Indirect Branch Restricted Speculation (IBRS)
* SPEC_CTRL MSR is available:  NO
* CPU indicates IBRS capability:  NO
  * Indirect Branch Prediction Barrier (IBPB)
* PRED_CMD MSR is available:  NO
* CPU indicates IBPB capability:  NO
  * Single Thread Indirect Branch Predictors (STIBP)
* SPEC_CTRL MSR is available:  NO
* CPU indicates STIBP capability:  NO
  * Enhanced IBRS (IBRS_ALL)
* CPU indicates ARCH_CAPABILITIES MSR availability:  NO
* ARCH_CAPABILITIES MSR advertises IBRS_ALL capability:  NO
  * CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO):
NO
* CPU vulnerability to the three speculative execution attacks variants
  * Vulnerable to Variant 1:  YES
  * Vulnerable to Variant 2:  YES
  * Vulnerable to Variant 3:  NO

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface:  NO  (kernel confirms your
system is vulnerable)
> STATUS:  VULNERABLE  (Vulnerable)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface:  NO  (kernel confirms your
system is vulnerable)
* Mitigation 1
  * Kernel is compiled with IBRS/IBPB support:  NO
  * Currently enabled features
* IBRS enabled for Kernel space:  NO
* IBRS enabled for User space:  NO
* IBPB enabled:  NO
* Mitigation 2
  * Kernel compiled with retpoline option:  YES
  * Kernel compiled with a retpoline-aware compiler:  NO  (kernel reports
minimal retpoline compilation)
  * Retpoline enabled:  YES
> STATUS:  VULNERABLE  (Vulnerable: Minimal AMD ASM retpoline)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface:  YES  (kernel confirms that
your CPU is unaffected)
* Kernel supports Page Table Isolation (PTI):  YES
* PTI enabled and active:  NO
* Running under Xen PV (64 bits):  NO
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not
vulnerable)

A false sense of security is worse than no security at all, see --disclaimer
root@mikef-PC:/home/mikef/spectre-meltdown-checker#


I have the same problem as in Gentoo.

In order to install gcc 7.3 rc2 I think I would need to be sid.


I don't think I want to be sid at present.

Cheers

MF



​



>
> Regards
>
> Michael
>
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> War isn't a good life, but it's life.
> -- Kirk, "A Private Little War", stardate 4211.8
>
>

Re: Question on CVE-2017-5754 on Debian 8.9

[Michael Fothergill]

>
>
> I have the same problem as in Gentoo.
>
> In order to install gcc 7.3 rc2 I think I would need to be sid.
>
>
> I don't think I want to be sid at present.
>

​But if I did want to be sid, would a source file like this suffice:

​
deb http://http.us.debian.org/debian/ unstable main contrib non-free
deb-src http://http.us.debian.org/debian/ unstable main contrib non-free

​or do I need more?

​If I become sid then I think I would just install the gcc version above
the one I have and  then reinstall
the 4.15.0 kernel and maybe I would have the full kernel patch.

Comments appreciated,




>
> Cheers
>
> MF
>
>
>
> ​
>
>
>
>>
>> Regards
>>
>> Michael
>>
>>
>> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>>
>> War isn't a good life, but it's life.
>> -- Kirk, "A Private Little War", stardate 4211.8
>>
>>
>

Re: Question on CVE-2017-5754 on Debian 8.9

[Michael Fothergill]

On 25 January 2018 at 09:50, Michael Lange  wrote:

> Hi,
>
> On Thu, 25 Jan 2018 09:15:59 +
> Michael Fothergill  wrote:
>
> > >
> > >
> > > I have the same problem as in Gentoo.
> > >
> > > In order to install gcc 7.3 rc2 I think I would need to be sid.
> > >
> > >
> > > I don't think I want to be sid at present.
> > >
> >
> > ​But if I did want to be sid, would a source file like this suffice:
> >
> > ​
> > deb http://http.us.debian.org/debian/ unstable main contrib non-free
> > deb-src http://http.us.debian.org/debian/ unstable main contrib non-free
> >
> > ​or do I need more?
> >
> > ​If I become sid then I think I would just install the gcc version above
> > the one I have and  then reinstall
> > the 4.15.0 kernel and maybe I would have the full kernel
> > patch.
>
> hmm, I don't think installing the latest compiler does any good if you
> install a kernel package that was compiled with an older compiler version.
>
> And from a quick glance it looks like sid still has only gcc-7.2 .
> There is a gcc-8 package in experimental though; from again a quick
> glance at the dependencies it surely won't easily install on stretch but
> it might be worth a try if it installs on buster.
>

​I tried installing gcc 8 on buster.   It needs cpp8 which needs ​libmrpfr6

ie this

https://packages.debian.org/unstable/main/libmpfr6

which looks like its about being sid again.​


​I need to go to dependency rehab and sing the dem bones song again.

Suggestions on avoiding becoming sid/krankenhaus/unstable/12 step program
welcome.

Regards

MF


 ​


> Then I guess you would have to compile the kernel from source, which
> actually isn't too hard with make-kpkg (however I never tried to force
> make-kpkg to use a certain, non-system-default compiler, but that's surely
> possible).
>
> Regards
>
> Michael
>
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> Every living thing wants to survive.
> -- Spock, "The Ultimate Computer", stardate 4731.3
>
>

Re: Question on CVE-2017-5754 on Debian 8.9

[Michael Fothergill]

>>
> ​I tried installing gcc 8 on buster.   It needs cpp8 which needs
> ​libmrpfr6
>
> ie this
>
> https://packages.debian.org/unstable/main/libmpfr6
>
> which looks like its about being sid again.​
>
>
> ​I need to go to dependency rehab and sing the dem bones song again.
>
> Suggestions on avoiding becoming sid/krankenhaus/unstable/12 step program
> welcome.
>
> Regards
>
> MF
>

​If I become sid and install the kernel correctly, could I go back to being
just buster (sounds like an energy drink) and carry on using the new kernel?

Cheers

MF



​


>
>
>  ​
>
>
>> Then I guess you would have to compile the kernel from source, which
>> actually isn't too hard with make-kpkg (however I never tried to force
>> make-kpkg to use a certain, non-system-default compiler, but that's surely
>> possible).
>>
>> Regards
>>
>> Michael
>>
>>
>> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>>
>> Every living thing wants to survive.
>> -- Spock, "The Ultimate Computer", stardate 4731.3
>>
>>
>

Re: Question on CVE-2017-5754 on Debian 8.9

[Michael Fothergill]

On 25 January 2018 at 13:01, Greg Wooledge  wrote:

> On Thu, Jan 25, 2018 at 12:36:46PM +0000, Michael Fothergill wrote:
> > ​If I become sid and install the kernel correctly, could I go back to
> being
> > just buster (sounds like an energy drink) and carry on using the new
> kernel?
>
> No.
>
> ​It seems I have to become sid here.


MF​

Re: Question on CVE-2017-5754 on Debian 8.9

[Michael Fothergill]

On 25 January 2018 at 13:14, Michael Fothergill <
michael.fotherg...@gmail.com> wrote:

>
>
> On 25 January 2018 at 13:01, Greg Wooledge  wrote:
>
>> On Thu, Jan 25, 2018 at 12:36:46PM +, Michael Fothergill wrote:
>> > ​If I become sid and install the kernel correctly, could I go back to
>> being
>> > just buster (sounds like an energy drink) and carry on using the new
>> kernel?
>>
>> No.
>>
>> ​It seems I have to become sid here.
>

​I have become sid and installed a ton of dependencies from the
experimental respository and finally installed gcc 8.

After some rehab I will study the web page on compiling kernels in debian.

I need to get the set up to use the GCC 8 compiler I have just installed.

Cheers

MF​



>
>
> MF​
>
>
>

Re: Question on CVE-2017-5754 on Debian 8.9

[Michael Fothergill]

On 25 January 2018 at 15:59, Michael Fothergill <
michael.fotherg...@gmail.com> wrote:

>
>
> On 25 January 2018 at 13:14, Michael Fothergill <
> michael.fotherg...@gmail.com> wrote:
>
>>
>>
>> On 25 January 2018 at 13:01, Greg Wooledge  wrote:
>>
>>> On Thu, Jan 25, 2018 at 12:36:46PM +, Michael Fothergill wrote:
>>> > ​If I become sid and install the kernel correctly, could I go back to
>>> being
>>> > just buster (sounds like an energy drink) and carry on using the new
>>> kernel?
>>>
>>> No.
>>>
>>> ​It seems I have to become sid here.
>>
>
> ​I have become sid and installed a ton of dependencies from the
> experimental respository and finally installed gcc 8.
>
> After some rehab I will study the web page on compiling kernels in debian.
>
> I need to get the set up to use the GCC 8 compiler I have just installed.
>
> Cheers
>
> MF​
>

​OK, I went through the dependency detox program (and had some electrodes
hooked up to my ears etc) and made a good recovery.

I looked at some web pages on the debian way of compiling kernels etc.

My general strategy is as follows:

1. Download the latest stable kernel from the kernel archives; this is
4.14.15 - I have done this.

2. Use the  tar xf /usr/src/linux-source-4.14.15.tar.xz command to unpack
the kernel source file.

​3. cd to the directory where the kernel source lives

4.  Reuse the config file from the 4.14.15 rc8 kernel I already have
installed e.g. cp /boot/config-3.16.0-4-amd64
~/kernel/linux-source-3.16/.config

5. run make menuconfig (I do this in gentoo) I will make sure
libncurses5-dev (or does it need to be newer?) is installed to configure it
using the recycled config file from 4 above.

6. Run make-kpkg clean.

7. Then run fakeroot make-kpkg --initrd --revision=1.0.custom kernel_image.

8. Then install the kernel as follows: dpkg -i
../linux-image-4.14.15-subarchitecture_1.0.custom_i386.deb.

9. Reboot and look for new kernel in grub menu and log in.

10. Run the patch checker to see that KPTI and retpoline patched are turned
on properly.

Please critique the above list.   I am going to read more documentation and
improve it before going ahead with this.

Cheers

MF

















>
>
>
>>
>>
>> MF​
>>
>>
>>
>

Re: Question on CVE-2017-5754 on Debian 8.9

[Michael Fothergill]

On 25 January 2018 at 17:20, Michael Lange  wrote:

> On Thu, 25 Jan 2018 15:59:04 +
> Michael Fothergill  wrote:
>
> > ​I have become sid and installed a ton of dependencies from the
> > experimental respository and finally installed gcc 8.
>
> Oh, from a quick glance it looked like half a dozen might suffice :-)
>
> >
> > After some rehab I will study the web page on compiling kernels in
> > debian.
> >
> > I need to get the set up to use the GCC 8 compiler I have just
> > installed.
>
> I have done this a lot lately (needed a custom kernel for a new laptop).
> Basically all I had to do was install make-kpkg + a number of other
> related packages. Once all that was in place I just had to pick a source
> tarball from kernel.org and unzip it, copy the latest config I had
> in /boot to linux-/.config , then run
>
> # yes "" | make oldconfig
>
> from within the source-directory and then start compiling with
> something like
>
> # fakeroot make-kpkg --initrd --append-to-version=-
> kernel-image kernel-headers
>
> The man page of make-kpkg gives hints about how to
> force a gcc version in its description paragraph, never tried this
> myself, though.
>

​I installed the kernel-package thing and then looked at the make-kpkg man
entry.

I couldn't find the option talking about choosing the gcc version you
mentioned - maybe the language was too coded for me.

Also​

​if I use this command:​

make ARCH=i386 defconfig

​should ARCH=amd64 or something be appropriate for me running my amd64
kaveri box here?​

​Also is fakeroot installed by default or do I need to install it
separately?

​Thanks for the hints here.

MF





>
> Good luck!!
>
> Michael
>
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> Computers make excellent and efficient servants, but I have no wish to
> serve under them.  Captain, a starship also runs on loyalty to one
> man.  And nothing can replace it or him.
> -- Spock, "The Ultimate Computer", stardate 4729.4
>
>

Re: Question on CVE-2017-5754 on Debian 8.9

[Michael Fothergill]

I have been looking at the web page here:

https://wiki.debian.org/BuildADebianKernelPackage

and noticed that the source file is supposed to be put in /usr/src it says.

It thinks the file would have a format like this:



*linux-source-x.x.tar.bz2*
The file
​ I downloaded from the kernel.org site looks like this:

​

linux-4.14.15.tar.xz

I think that is the same thing here (please correct me if I am wrong).

It is currently sitting in my Downloads directory.

I am going to move it to the /usr/src directory and then run the other
commands.

Cheers

MF

extracting file with xz file tar.....

[Michael Fothergill]

Dear folks,

I am trying to extract files from a tar xz file.

The file is a kernel file.

I ran the tar -xf command:

root@mikef-PC:/usr/src# tar -xf linux-4.14.15.tar.xz

If you look at the date and time then you can see that no directories have
been created with from it in the directory.

root@mikef-PC:/usr/src# date
Thu 25 Jan 20:11:23 GMT 2018
root@mikef-PC:/usr/src# ls -l
total 12
drwxrwxr-x 24 root  root   4096 Jan 23 18:58 linux-4.14.15
-rw-r--r--  1 mikef mikef 100837776 Jan 25 16:43 linux-4.14.15.tar.xz
drwxr-xr-x  2 root  root   4096 Jan 25 18:02 linux-config-4.14
drwxr-xr-x  4 root  root   4096 Jan 25 00:01
linux-headers-4.14.0-3-amd64
drwxr-xr-x  4 root  root   4096 Jan 25 00:01
linux-headers-4.14.0-3-common
drwxr-xr-x  4 root  root   4096 Jan 24 16:32 linux-headers-4.9.0-4-amd64
drwxr-xr-x  4 root  root   4096 Jan 24 16:33
linux-headers-4.9.0-4-common
lrwxrwxrwx  1 root  root 24 Jan 14 19:45 linux-kbuild-4.14 ->
../lib/linux-kbuild-4.14
lrwxrwxrwx  1 root  root 24 Jan 15 04:43 linux-kbuild-4.15 ->
../lib/linux-kbuild-4.15
lrwxrwxrwx  1 root  root 23 Aug  6 05:24 linux-kbuild-4.9 ->
../lib/linux-kbuild-4.9
-rw-r--r--  1 root  root 216052 Jan 14 19:45
linux-patch-4.14-rt.patch.xz
-rw-r--r--  1 root  root  103701828 Jan 14 19:45 linux-source-4.14.tar.xz
drwxr-xr-x  8 root  root   4096 Nov 18 09:15 open-vm-tools-10.1.5
root@mikef-PC:/usr/src#

Can anyone think of a command that will let me know where the files
went/confirm it ran properly?

Cheers

Michael Fothergill

Re: Question on CVE-2017-5754 on Debian 8.9

[Michael Fothergill]

On 25 January 2018 at 19:25, Brian  wrote:

> On Thu 25 Jan 2018 at 18:15:29 +0000, Michael Fothergill wrote:
>
> > Also is fakeroot installed by default or do I need to install it
> > separately?
>
> apt show fakeroot | grep -i priority
>
> What do you think?
>
> > Thanks for the hints here.
>
> Where are we going? It seems a long time getting there. :)
>

​It's OK.  I ran apt show fakeroot | grep -i priority
​
 and got:

root@mikef-PC:/usr/src# apt show fakeroot | grep -i priority

WARNING: apt does not have a stable CLI interface. Use with caution in
scripts.

Priority: optional
root@mikef-PC:/usr/src#

Also I put the kernel file in /usr/src and then
ran the following:

tar -xaf linux-4.14.15.tar.xz

It seemed to run OK but I don't know where it put the unpacked files.

The creation dates show etc they are not in the /usr/src directory or in a
new directory created in it.

Some docs say you shouldn't put the src files in the src directory - but
others do.

Bit odd.

Comments appreciated.

Regards

MF


--
> Brian.
>
>

Re: extracting file with xz file tar.....

[Michael Fothergill]

On 25 January 2018 at 20:33, Greg Wooledge  wrote:

> On Thu, Jan 25, 2018 at 08:14:24PM +0000, Michael Fothergill wrote:
> > root@mikef-PC:/usr/src# tar -xf linux-4.14.15.tar.xz
> >
> > Can anyone think of a command that will let me know where the files
> > went/confirm it ran properly?
>
> Use "tar -xvf ..." to get verbose output (filenames) during the extraction.
>

​Many thanks,  I did this and then realised that the creation date of Jan
23rd for the linux 4.14.15 directory created is for this kernel - that is
the date given for it being made on the kernel.org site.

I now what planet I am on here with this.

A trap here was that I already have a kernel installed which is 4.14.15 rc8
so I could have ​mistaken it for that so it was not as simple as looking
for a file with 4.14.15 in it etc in /usr/src etc.

It's OK.

I will try copying the config file from the 4.14.15rc8 kernel (where ever
that might live - I am going to have to learn to find them by sense of
smell) and use it for the compilation.

Cheers

MF




>
> Or, use "tar -tvf ..." to get a table of contents of the archive.
> (You probably want to pipe that through less, or some other pager.)
>
>

Re: Question on CVE-2017-5754 on Debian 8.9

[Michael Fothergill]

> Not sure, but didn't you want the very latest 4.15rc for some
> Meltdown/Spectre issues? Are these also in 4.14.15?
>
> ​
>

​I copied the config file from the boot directory for the current 4.15.0
rc8 kernel as .config.

I then ran make menuconfig and then realised I didn't need to change
anything and exited.

I didn't run your

yes ""|  make oldconfig thing - it seemed a bit peculiar to me.

Maybe I should have.

Instead I ran the command recommended here:

https://wiki.debian.org/BuildADebianKernelPackage

which was

make ARCH=i386 defconfig

I then ran

make-kpkg

and it then asked me lots of questions concerning kernel options that I had
to answer interactively.

I think I should have tried your funny quotation pipe command with the
oldconfig option - it would have been better.

​​

​Here is some of the output before it crashed:​



kexec system call (KEXEC) [Y/n/?] y
kexec file based system call (KEXEC_FILE) [N/y/?] n
kernel crash dumps (CRASH_DUMP) [Y/n/?] y
kexec jump (KEXEC_JUMP) [N/y/?] n
Physical address where the kernel is loaded (PHYSICAL_START) [0x100]
0x100
Build a relocatable kernel (RELOCATABLE) [Y/n/?] y
  Randomize the address of the kernel image (KASLR) (RANDOMIZE_BASE)
[Y/n/?] y
Alignment value to which kernel should be aligned (PHYSICAL_ALIGN)
[0x20] 0x20
Randomize the kernel memory sections (RANDOMIZE_MEMORY) [Y/n/?] y
Support for hot-pluggable CPUs (HOTPLUG_CPU) [Y/?] y
  Set default setting of cpu0_hotpluggable (BOOTPARAM_HOTPLUG_CPU0) [N/y/?]
n
  Debug CPU0 hotplug (DEBUG_HOTPLUG_CPU0) [N/y/?] n
vsyscall table for legacy applications
  1. Native (LEGACY_VSYSCALL_NATIVE)
> 2. Emulate (LEGACY_VSYSCALL_EMULATE)
  3. None (LEGACY_VSYSCALL_NONE)
choice[1-3?]: 2
Built-in kernel command line (CMDLINE_BOOL) [N/y/?] n
#
# configuration written to .config
#
make[2]: Leaving directory '/usr/src/linux-4.14.15'
make\
 ARCH=x86_64  dep
make[2]: Entering directory '/usr/src/linux-4.14.15'
Makefile:942: *** "Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y,
please install libelf-dev, libelf-devel or elfutils-libelf-devel".  Stop.
make[2]: Leaving directory '/usr/src/linux-4.14.15'
debian/ruleset/targets/common.mk:194: recipe for target
'debian/stamp/conf/kernel-conf' failed
make[1]: *** [debian/stamp/conf/kernel-conf] Error 2
make[1]: Leaving directory '/usr/src/linux-4.14.15'
/usr/share/kernel-package/ruleset/minimal.mk:93: recipe for target
'debian/stamp/conf/minimal_debian' failed
make: *** [debian/stamp/conf/minimal_debian] Error 2
Failed to create a ./debian directory:  at /usr/bin/make-kpkg line 970.
root@mikef-PC:/usr/src/linux-4.14.15#


It has written things to the config file so I think I might be wise to
delete it, copy it over again
and repeat everything with the Shakespearian pipe command next time.



Suggestions on recovering gracefully here are welcome.

Regards

MF




> ​
>
>
>
>
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> It would be illogical to assume that all conditions remain stable.
> -- Spock, "The Enterprise Incident", stardate 5027.3
>
>

Re: Question on CVE-2017-5754 on Debian 8.9

[Michael Fothergill]

Dear All,

I ran it again after deleting the .config file, copy the one /boot over
again
and running the yes """| oldconfig command and makekpkg

and it ran and crashed again:

https://pastebin.com/GJkEMVvc


​Should I have run make clean or something before repeating everything?

Regards

MF​

Re: Question on CVE-2017-5754 on Debian 8.9

[Michael Fothergill]

On 25 January 2018 at 22:04, Michael Fothergill <
michael.fotherg...@gmail.com> wrote:

> Dear All,
>
> I ran it again after deleting the .config file, copy the one /boot over
> again
> and running the yes """| oldconfig command and makekpkg
>
> and it ran and crashed again:
>
> https://pastebin.com/GJkEMVvc
>
>
> ​Should I have run make clean or something before repeating everything?
>
> Regards
>
> MF​
>

​Dear All,

I am going to carry on with this discussion in a new post on kernel
compilation.

Thanks

MF​

kernel 4.14.15 compilation using GCC 8 in unstable.......

[Michael Fothergill]

Dear All,

I am continuing the discussion of the kernel 4.14.15 compilation in the
Question on CVE-2017-5754 on Debian 8.9 post in a new post.

The reason I am running with this kernel and not the 4.15.0 rc9 kernel that
is now available on kernel.org is that:

1. It is stable

2. I have never tried to compile a kernel in Debian before and want to make
it a bit easier for me the first time would try.

3.  kernel 4.14.15 does have the KPTI and retpoline patches in it, so it is
a fair candidate for the GCC8 compiler to produce a kernel that the patch
checker could confirm has these meltdown and spectre fixes are properly set
up and active.

Cheers

Regards

MF

Re: Question on CVE-2017-5754 on Debian 8.9

[Michael Fothergill]

On 25 January 2018 at 22:35, Michael Lange  wrote:

> Hi,
>
> On Thu, 25 Jan 2018 21:43:19 +
> Michael Fothergill  wrote:
>
> > > Not sure, but didn't you want the very latest 4.15rc for some
> > > Meltdown/Spectre issues? Are these also in 4.14.15?
> > >
> > > ​
> > >
> >
> > ​I copied the config file from the boot directory for the current 4.15.0
> > rc8 kernel as .config.
> >
> > I then ran make menuconfig and then realised I didn't need to change
> > anything and exited.
> >
> > I didn't run your
> >
> > yes ""|  make oldconfig thing - it seemed a bit peculiar to me.
> >
> > Maybe I should have.
> >
> > Instead I ran the command recommended here:
> >
> > https://wiki.debian.org/BuildADebianKernelPackage
> >
> > which was
> >
> > make ARCH=i386 defconfig
>
> Didn't want to build for amd64? If yes, you should have followed the
> advice from that page saying:
> "Create a defconfig with the following command, please change ARCH=i386
>
to match your target architecture:"
> I only built kernel packages for amd64 on an amd64 system, so I never had
> to explicitely specify ARCH.
>

​Should it not be ARCH =​x86-64 rather than amd64.

It is so confusing.

MF

>
>  >
> > I then ran
> >
> > make-kpkg
> >
> > and it then asked me lots of questions concerning kernel options that I
> > had to answer interactively.
> >
> > I think I should have tried your funny quotation pipe command with the
> > oldconfig option - it would have been better.
>
> Actually I don't remember which tutorial I borrowed this from; as far as
> I know it will set the default values for any new option not present in
> the old config.
>
> >
> > ​​
> >
> > ​Here is some of the output before it crashed:​
> >
> >
> >
> > kexec system call (KEXEC) [Y/n/?] y
> > kexec file based system call (KEXEC_FILE) [N/y/?] n
> > kernel crash dumps (CRASH_DUMP) [Y/n/?] y
> > kexec jump (KEXEC_JUMP) [N/y/?] n
> > Physical address where the kernel is loaded (PHYSICAL_START) [0x100]
> > 0x100
> > Build a relocatable kernel (RELOCATABLE) [Y/n/?] y
> >   Randomize the address of the kernel image (KASLR) (RANDOMIZE_BASE)
> > [Y/n/?] y
> > Alignment value to which kernel should be aligned (PHYSICAL_ALIGN)
> > [0x20] 0x20
> > Randomize the kernel memory sections (RANDOMIZE_MEMORY) [Y/n/?] y
> > Support for hot-pluggable CPUs (HOTPLUG_CPU) [Y/?] y
> >   Set default setting of cpu0_hotpluggable (BOOTPARAM_HOTPLUG_CPU0)
> > [N/y/?] n
> >   Debug CPU0 hotplug (DEBUG_HOTPLUG_CPU0) [N/y/?] n
> > vsyscall table for legacy applications
> >   1. Native (LEGACY_VSYSCALL_NATIVE)
> > > 2. Emulate (LEGACY_VSYSCALL_EMULATE)
> >   3. None (LEGACY_VSYSCALL_NONE)
> > choice[1-3?]: 2
> > Built-in kernel command line (CMDLINE_BOOL) [N/y/?] n
> > #
> > # configuration written to .config
> > #
> > make[2]: Leaving directory '/usr/src/linux-4.14.15'
> > make\
> >  ARCH=x86_64  dep
> > make[2]: Entering directory '/usr/src/linux-4.14.15'
> > Makefile:942: *** "Cannot generate ORC metadata for
> > CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel or
> > elfutils-libelf-devel".  Stop. make[2]: Leaving directory
> > '/usr/src/linux-4.14.15' debian/ruleset/targets/common.mk:194: recipe
> > for target 'debian/stamp/conf/kernel-conf' failed
> > make[1]: *** [debian/stamp/conf/kernel-conf] Error 2
> > make[1]: Leaving directory '/usr/src/linux-4.14.15'
> > /usr/share/kernel-package/ruleset/minimal.mk:93: recipe for target
> > 'debian/stamp/conf/minimal_debian' failed
> > make: *** [debian/stamp/conf/minimal_debian] Error 2
> > Failed to create a ./debian directory:  at /usr/bin/make-kpkg line 970.
> > root@mikef-PC:/usr/src/linux-4.14.15#
>
> Funny thing: just for the sport I tried the same thing on a siduction
> system this evening and ended up with the same error message.
> Had no time to investigate yet, it looks a bit like this one:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804813
>
> but this one's old and claims to be solved.
> Here:
> http://forums.debian.net/viewtopic.php?t=74424
> it is suggested that an upper case letter in the path to the sources
> might be the culprit, but then I have upper case characters here on
> stretch too, which didn't harm.
> Here:
> http://forums.debian.net/viewtopic

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

[Michael Fothergill]

On 25 January 2018 at 23:28, Michael Lange  wrote:

> Hi,
>
> On Thu, 25 Jan 2018 22:23:38 +
> Michael Fothergill  wrote:
>
> > Dear All,
> >
> > I am continuing the discussion of the kernel 4.14.15 compilation in the
> > Question on CVE-2017-5754 on Debian 8.9 post in a new post.
> >
> > The reason I am running with this kernel and not the 4.15.0 rc9 kernel
> > that is now available on kernel.org is that:
> >
> > 1. It is stable
> >
> > 2. I have never tried to compile a kernel in Debian before and want to
> > make it a bit easier for me the first time would try.
> >
> > 3.  kernel 4.14.15 does have the KPTI and retpoline patches in it, so
> > it is a fair candidate for the GCC8 compiler to produce a kernel that
> > the patch checker could confirm has these meltdown and spectre fixes
> > are properly set up and active.
>
> Ok, my advice if you don't want to give up yet :-)
>
> Don't try to force the use of gcc-8 until you know that everything runs
> properly with the default compiler.
>
> Maybe you should follow the advice from the previously posted error
> message:
>
> "make[2]: Entering directory '/usr/src/linux-4.14.15'
> Makefile:942: *** "Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y,
> please install libelf-dev, libelf-devel or elfutils-libelf-devel".  Stop."
>^
>

​Many thanks.  I can think of some things that might help a bit here.

1. I could try out the ​
 gcc-h...@gcc.gnu.org
​mailing list for suggestions on how to proceed here.​ They might know
which elf packages was important here etc.

2.  I could check the dependencies on the experimental page for the
compiler and see if the elf libraries are listed in it and then pick the
right one and install it.

3.  I could be cheered by the fact that gentoo has just made a basic build
file for gcc 7.3: (https://packages.gentoo.org/packages/sys-devel/gcc) - an
advert for gentoo I would say.

Regards

MF




> (Ignore the messages about the debian directory.)
> If similar messages as the above appear again, try to figure out what
> needs to be additionally installed (some *-dev packages might still be
> missing).
>
> Once you get past the first few minutes of the procedure when using the
> default compiler and you see how one module after the other is compiled,
> hit Ctrl-C, do "make mrproper" and start over again with gcc-8.
>
> This is just my 2¢, but I believe "debugging" one thing at a time is the
> more promising approach here.
>
> Good luck (and for now good night :)
>
> Michael
>
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> Virtue is a relative term.
> -- Spock, "Friday's Child", stardate 3499.1
>
>

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

[Michael Fothergill]

>>
> Hi, sorry to jump into the thread this late, I didn't follow the beginning.
> You can save yourself quite a bit of hassle by downloading the upstream
> up-to-date vanilla kernel 4.15-rc9 and compile that with Unstable gcc-7.
> All you need is there already and you will get as good a mitigation for
> Spectre as one can get right now.


​Is the 7.2 kernel in sid gcc 7 really gassed up enough to compile the
spectre fix in a way that the meltdown-spectre checker will say that the
compiler used
was adequate to make the kernel fix work properly?​ A backport from GCC 8
to 7 has to be made to make it work - I thought this was only done in
7.3...

​Is the sid gcc now 7.3 as someone said earlier even though it says it is
7.2?

I don't want to have to uninstall gcc 8 only to have to reinstall it again.

MF​




> After configuration you can use the build target "make bindeb-pkg" or use
> the "make-kpkg" command from kernel-package (to be installed and
> configured, the doc will guide you).
> Also you need basic build environment, and "libelf-dev" if you choose the
> ORC unwinder. For the build environment look at kernel-package dependencies.
>
> If you want to stay mainly in Testing but cherry pick Unstable packages
> (and benefit from apt/aptitude dependencies resolution) you can look into
> apt-pinning, giving Unstable package a priority of 101 should do the trick,
> something like:
>
> Package: *
> Pin: release a=unstable
> Pin-Priority: 101
>
> in /etc/apt/preferences, coupled with:
>
> APT::Default-Release "buster";
>
> in /etc/apt/apt.conf
>
>
> I would not pull critical packages from experimental unless it is
> absolutely necessary, dragons are lurking in there.
>
> Hope it helps.
>
>

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

[Michael Fothergill]

On 26 January 2018 at 16:17, Michael Fothergill <
michael.fotherg...@gmail.com> wrote:

>
>
>
>
>>>
>> Hi, sorry to jump into the thread this late, I didn't follow the
>> beginning.
>> You can save yourself quite a bit of hassle by downloading the upstream
>> up-to-date vanilla kernel 4.15-rc9 and compile that with Unstable gcc-7.
>> All you need is there already and you will get as good a mitigation for
>> Spectre as one can get right now.
>
>
> ​Is the 7.2 kernel in sid gcc 7 really gassed up enough to compile the
> spectre fix in a way that the meltdown-spectre checker will say that the
> compiler used
> was adequate to make the kernel fix work properly?
>

​Oops I made an error here. I meant to say:

Is the 7.2 version of the compiler in sid gcc 7 ​really gassed up enough to
compile the spectre fix in a way that the meltdown-spectre checker will say
that the compiler used
was adequate to make the kernel fix work properly?

Cheers

MF




> ​ A backport from GCC 8 to 7 has to be made to make it work - I thought
> this was only done in 7.3...
>
> ​Is the sid gcc now 7.3 as someone said earlier even though it says it is
> 7.2?
>
> I don't want to have to uninstall gcc 8 only to have to reinstall it again.
>
> MF​
>
>
>
>
>> After configuration you can use the build target "make bindeb-pkg" or use
>> the "make-kpkg" command from kernel-package (to be installed and
>> configured, the doc will guide you).
>> Also you need basic build environment, and "libelf-dev" if you choose the
>> ORC unwinder. For the build environment look at kernel-package dependencies.
>>
>> If you want to stay mainly in Testing but cherry pick Unstable packages
>> (and benefit from apt/aptitude dependencies resolution) you can look into
>> apt-pinning, giving Unstable package a priority of 101 should do the trick,
>> something like:
>>
>> Package: *
>> Pin: release a=unstable
>> Pin-Priority: 101
>>
>> in /etc/apt/preferences, coupled with:
>>
>> APT::Default-Release "buster";
>>
>> in /etc/apt/apt.conf
>>
>>
>> I would not pull critical packages from experimental unless it is
>> absolutely necessary, dragons are lurking in there.
>>
>> Hope it helps.
>>
>>
>

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

[Michael Fothergill]

On 26 January 2018 at 16:26, Michael Fothergill <
michael.fotherg...@gmail.com> wrote:

>
>
> On 26 January 2018 at 16:17, Michael Fothergill <
> michael.fotherg...@gmail.com> wrote:
>
>>
>>
>>
>>
>>>>
>>> Hi, sorry to jump into the thread this late, I didn't follow the
>>> beginning.
>>> You can save yourself quite a bit of hassle by downloading the upstream
>>> up-to-date vanilla kernel 4.15-rc9 and compile that with Unstable gcc-7.
>>> All you need is there already and you will get as good a mitigation for
>>> Spectre as one can get right now.
>>
>>
>> ​Is the 7.2 kernel in sid gcc 7 really gassed up enough to compile the
>> spectre fix in a way that the meltdown-spectre checker will say that the
>> compiler used
>> was adequate to make the kernel fix work properly?
>>
>
> ​Oops I made an error here. I meant to say:
>
> Is the 7.2 version of the compiler in sid gcc 7 ​really gassed up enough
> to compile the spectre fix in a way that the meltdown-spectre checker will
> say that the compiler used
> was adequate to make the kernel fix work properly?
>
> Cheers
>
> MF
>
>
>
>
>> ​ A backport from GCC 8 to 7 has to be made to make it work - I thought
>> this was only done in 7.3...
>>
>> ​Is the sid gcc now 7.3 as someone said earlier even though it says it is
>> 7.2?
>>
>> I don't want to have to uninstall gcc 8 only to have to reinstall it
>> again.
>>
>> MF​
>>
>
​ie the backport here is installed:​


https://www.phoronix.com/scan.php?page=news_item&px=GCC-7.3-Released



>
>>
>>
>>
>>> After configuration you can use the build target "make bindeb-pkg" or
>>> use the "make-kpkg" command from kernel-package (to be installed and
>>> configured, the doc will guide you).
>>> Also you need basic build environment, and "libelf-dev" if you choose
>>> the ORC unwinder. For the build environment look at kernel-package
>>> dependencies.
>>>
>>> If you want to stay mainly in Testing but cherry pick Unstable packages
>>> (and benefit from apt/aptitude dependencies resolution) you can look into
>>> apt-pinning, giving Unstable package a priority of 101 should do the trick,
>>> something like:
>>>
>>> Package: *
>>> Pin: release a=unstable
>>> Pin-Priority: 101
>>>
>>> in /etc/apt/preferences, coupled with:
>>>
>>> APT::Default-Release "buster";
>>>
>>> in /etc/apt/apt.conf
>>>
>>>
>>> I would not pull critical packages from experimental unless it is
>>> absolutely necessary, dragons are lurking in there.
>>>
>>> Hope it helps.
>>>
>>>
>>
>

Re: a potential investor and collaborator has shown a little interest in Climostat

[Michael Fothergill]

Dear Paul,

I think the Beefeater sounds like the best choice for me.

6.30 pm is a good time.

Regards

Michael

Climostat Ltd

On 26 January 2018 at 16:34, Paul Barnard  wrote:

> The Beefeater or the Ring of Bells would be good.
>
> Early evening would be best for me - say 6.30?  But I'm flexible on this.
>
> Cheers,
> Paul
>
>
>
> On 26/01/2018 16:08, Michael Fothergill wrote:
>
> Dear Paul,
>
> Many thanks for the offer.
>
> I need to think of a good place to have a meal round here.
>
> We could try e.g. the Beefeater at Preston Brook or the Ring of Bells in
> Frodsham.
>
> Restaurants in Runcorn itself are not very fancy - there is a Pizza Hut in
> the Halton Lea business park that is not that bad.
>
> I think you might have eaten there once before.  That might also work.
>
> What time of day would be best for this next Friday?
>
> Cheers
>
> Michael
>
> Climostat Ltd
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On 26 January 2018 at 15:54, Paul Barnard  wrote:
>
>> Michael,
>>
>> I will be staying in Runcorn on Friday night, 2nd Feb.
>> Can I treat you to dinner somewhere?
>>
>> Cheers,
>> Paul
>>
>>
>> On 24/01/2018 18:02, Michael Fothergill wrote:
>>
>> Dear Paul,
>>
>> Many thanks for the reply.
>>
>> I will let you know how the meeting went.
>>
>> Cheers
>>
>> Michael
>>
>> Climostat Ltd
>>
>>
>>
>> On 24 January 2018 at 18:00, Paul Barnard  wrote:
>>
>>> This sounds good.
>>> The file you sent me doesn't help very much, since it is limited to the
>>> UK subsidiary.
>>>
>>> I suggest you prepare a 1-page briefing note for the meeting, in concise
>>> bullet point format.
>>>
>>> Good luck!
>>>
>>> --Paul
>>>
>>>
>>> On 23/01/2018 21:56, Michael Fothergill wrote:
>>>
>>> Dear Paul,
>>>
>>> I have agreed a meeting with the executive from Calysta  at the Wilton
>>> site in February.
>>>
>>> Regards
>>>
>>> Michael
>>>
>>> Climostat Ltd
>>>
>>>
>>> On 22 January 2018 at 20:25, Michael Fothergill <
>>> michael.fotherg...@gmail.com> wrote:
>>>
>>>> Dear Paul,
>>>>
>>>>
>>>> Happy New Year!
>>>>
>>>>
>>>> I am emailing to let you know that a US firm, with a UK subsidiary
>>>> based in Wilton, Teeside called Calysta (http://calysta.com/) has
>>>> taken a bit of interest in Climostat.
>>>>
>>>> This firm is making protein from methanotrophs to be used a foodstuff
>>>> for fish and other animals. They are building a plant in the US that will
>>>> produce 200,000 tonnes a year of the product.
>>>>
>>>> It will be the largest gas fermentation plant in the world.
>>>>
>>>> They have several investors including Cargill which is a large US food
>>>> business with 10 employees.
>>>>
>>>> One of their executives is coming to Teeside early in February.
>>>>
>>>> They are suggesting either a phone chat or meeting.
>>>>
>>>> I am at present thinking to ask for a meeting with them in Wilton.
>>>>
>>>> I have attached the companies house filing for the UK subsidiary to
>>>> this email.
>>>>
>>>> I hope the file is not too big to make it to your end.
>>>>
>>>> Wish me luck on this.
>>>>
>>>>
>>>> Regards
>>>>
>>>>
>>>> Michael
>>>>
>>>>
>>>> Climostat Ltd
>>>>
>>>
>>>
>>>
>>> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>>>  Virus-free.
>>> www.avg.com
>>> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>>> <#m_-8005761731079589519_m_5175262189285330254_m_8763593929054024126_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>
>>>
>>>
>>
>>
>
>

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

[Michael Fothergill]

On 26 January 2018 at 16:37, Greg Wooledge  wrote:

> On Fri, Jan 26, 2018 at 04:17:27PM +0000, Michael Fothergill wrote:
> > ​Is the sid gcc now 7.3 as someone said earlier even though it says it is
> > 7.2?
>
> Sid apparently has both "gcc" and "gcc-7" packages.
>
> https://packages.debian.org/sid/gcc shows version 7.2.0-1d1.
>
> https://packages.debian.org/sid/gcc-7 shows version 7.3.0-1.
>
> As a sid user, YOU should be capable of performing this kind of search
> (using apt-cache, apt, aptitude, http://packages.debian.org/ and other
> resources).
>
> ​E.g. remote viewing.  I installed gcc7 but the other day but the compiler
installed was billed as 7.2.20 or something.

Maybe it's been upgraded since then.



> As for whether the compiler implements whatever Spectre workaround
> you're looking for ... who knows?  It's sid.  Test it and report
> the results.  That's what sid is for.
>

​If it really is gcc 7.3 it should be able to do it.

Regards

MF

​

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

[Michael Fothergill]

On 26 January 2018 at 16:49, tv.deb...@googlemail.com <
tv.deb...@googlemail.com> wrote:

> On 26/01/2018 22:08, Michael Lange wrote:
>
>> Hi,
>>
>> On Fri, 26 Jan 2018 21:34:51 +0530
>> "tv.deb...@googlemail.com"  wrote:
>>
>> Hi, sorry to jump into the thread this late, I didn't follow the
>>> beginning. You can save yourself quite a bit of hassle by downloading
>>> the upstream up-to-date vanilla kernel 4.15-rc9 and compile that with
>>> Unstable gcc-7. All you need is there already and you will get as good
>>> a mitigation for Spectre as one can get right now.
>>>
>>
>> well, I just saw that gcc-7.3 arrived in sid today, so at least the
>> issues with gcc-8 from experimental seem to be history.
>> As far as I know the gcc-7.2 that was the latest in sid until yesterday
>> was not the best option in this regard.
>>
>> Just for the fun of it I got rid of gcc-8 now and upgraded to gcc-7.3; at
>> least now the kernel started to compile properly. Didn't have time right
>> now to let it finish though, since I had to boot again into stretch.
>> Probably there is a good chance that by tomorrow or so we can get a
>> kernel-image upgrade from sid anyway.
>>
>> Regards
>>
>> Michael
>>
>>
>>
>> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>>
>> I am pleased to see that we have differences.  May we together become
>> greater than the sum of both of us.
>> -- Surak of Vulcan, "The Savage Curtain", stardate 5906.4
>>
>>
> gcc-7[.2] was really gcc-7.3-rc for a while,


​That's what someone said to me earlier, but when I installed gcc7 as sid
the other day it said I had installed 7.2.20 or something and I did wonder
if it really was 7.3-rc instead
but I don't think apt-cache or some other fantastic search tool would tell
me that

I seem to recall other people saying it wouldn't work so instead of
reaching for dowsing rod or a ouija board I installed GCC8.

MF​



> and was doing a good job at enabling Spectre mitigation (as tested by the
> spectre-meltdown-checker and /sys/devices/system/cpu/vulnerabilities/*
> entries).
> No it is really gcc-7.3 and is fully capable.
>
> I have not tested with a 4.4.15 kernel yet, but that should work too since
> most (all?) mitigation have been back-ported by now.
>
> That leave the firmware/microcode as the ugly blind spot since we depend
> on chips and boards manufacturers to design and distribute working code.
>
>

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

[Michael Fothergill]

On 26 January 2018 at 17:18, tv.deb...@googlemail.com <
tv.deb...@googlemail.com> wrote:

> On 26/01/2018 22:37, Michael Lange wrote:
>
>> On Fri, 26 Jan 2018 22:19:27 +0530
>> "tv.deb...@googlemail.com"  wrote:
>>
>>
>>> gcc-7[.2] was really gcc-7.3-rc for a while, and was doing a good job
>>> at enabling Spectre mitigation (as tested by the
>>> spectre-meltdown-checker and /sys/devices/system/cpu/vulnerabilities/*
>>> entries). No it is really gcc-7.3 and is fully capable.
>>>
>>> I have not tested with a 4.4.15 kernel yet, but that should work too
>>> since most (all?) mitigation have been back-ported by now.
>>>
>>
>> I am definitely anything but an expert on this; but with sid's 4.14.15
>> (which I assumed was compiled with said gcc-7.2) the script here says:
>>
>> ##
>> Hardware check
>> * Hardware support (CPU microcode) for mitigation techniques
>>* Indirect Branch Restricted Speculation (IBRS)
>>  * SPEC_CTRL MSR is available:  UNKNOWN  (couldn't
>> read /dev/cpu/0/msr, is msr support enabled in your kernel?)
>>  * CPU indicates IBRS capability:  UNKNOWN  (couldn't
>> read /dev/cpu/0/cpuid, is cpuid support enabled in your kernel?)
>>* Indirect Branch Prediction Barrier (IBPB)
>>  * PRED_CMD MSR is available:  UNKNOWN  (couldn't read /dev/cpu/0/msr,
>> is msr support enabled in your kernel?)
>>  * CPU indicates IBPB capability:  UNKNOWN  (couldn't
>> read /dev/cpu/0/cpuid, is cpuid support enabled in your kernel?)
>>* Single Thread Indirect Branch Predictors (STIBP)
>>  * SPEC_CTRL MSR is available:  UNKNOWN  (couldn't
>> read /dev/cpu/0/msr, is msr support enabled in your kernel?)
>>  * CPU indicates STIBP capability:  UNKNOWN  (couldn't
>> read /dev/cpu/0/cpuid, is cpuid support enabled in your kernel?)
>>* Enhanced IBRS (IBRS_ALL)
>>  * CPU indicates ARCH_CAPABILITIES MSR availability:  UNKNOWN
>> (couldn't read /dev/cpu/0/cpuid, is cpuid support enabled in your kernel?)
>>  * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability:  NO
>>* CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO):
>> NO
>> * CPU vulnerability to the three speculative execution attacks variants
>>* Vulnerable to Variant 1:  YES
>>* Vulnerable to Variant 2:  YES
>>* Vulnerable to Variant 3:  NO
>>
>> CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
>> * Mitigated according to the /sys interface:  NO  (kernel confirms your
>> system is vulnerable)
>>
>>> STATUS:  VULNERABLE  (Vulnerable)
>>>
>>
>> CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
>> * Mitigated according to the /sys interface:  NO  (kernel confirms your
>> system is vulnerable)
>> * Mitigation 1
>>* Kernel is compiled with IBRS/IBPB support:  NO
>>* Currently enabled features
>>  * IBRS enabled for Kernel space:  NO
>>  * IBRS enabled for User space:  NO
>>  * IBPB enabled:  NO
>> * Mitigation 2
>>* Kernel compiled with retpoline option:  YES
>>* Kernel compiled with a retpoline-aware compiler:  NO  (kernel reports
>> minimal retpoline compilation)
>>* Retpoline enabled:  YES
>>
>>> STATUS:  VULNERABLE  (Vulnerable: Minimal AMD ASM retpoline)
>>>
>>
>> CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
>> * Mitigated according to the /sys interface:  YES  (kernel confirms that
>> your CPU is unaffected)
>> * Kernel supports Page Table Isolation (PTI):  YES
>> * PTI enabled and active:  UNKNOWN  (dmesg truncated, please reboot and
>> relaunch this script)
>> * Running under Xen PV (64 bits):  UNKNOWN  (dmesg truncated, please
>> reboot and relaunch this script)
>>
>>> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as
>>> not vulnerable)
>>>
>>
>> A false sense of security is worse than no security at all, see
>> --disclaimer
>>
>> ###
>>
>> I have no idea though if this is due to my hardware, the compiler or the
>> kernel. Maybe for the fun of it I'll try to compile 4.15rc9 later with
>> that new gcc-7.3 and see what happens.
>>
>> Regards
>>
>> Michael
>>
>> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>>
>> I'm a soldier, not a diplomat.  I can only tell the truth.
>> -- Kirk, "Errand of Mercy", stardate 3198.9
>>
>>
> Tested with upstream vanilla 4.14.15 compiled with current Sid gcc-7.3, i
> get a pass for Spectre v2 (full generic retpoline) and Meltdown (a.k.a.
> "v3").
>
> Spectre v1 is still vulnerable, but that will stay that way for a while.
>

​Sounds like it believes in your the compiler and it has worked 100%.

Cheers

MF​


>
> This is on an Intel Kaby Lake system (my only Intel system at he moment).
>

​I would buy AMD from now on.

MF​


>
> PS: apologies for writing the previous message with my feet, it should
> read "4.14.15 kernel" and NOT "4.4.15", and "now" instead of "no"...
>
>

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

[Michael Fothergill]

​Dear All,

I have decided to get rid of GCC8 using ML's helpful command suggestion.

I will install gcc 7 again as sid and try again with kernel 4.14.15.

​Cheers

MF



>

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

[Michael Fothergill]

On 26 January 2018 at 22:59, Michael Lange  wrote:

> On Fri, 26 Jan 2018 23:41:07 +0100
> Michael Lange  wrote:
>
> > When I check /proc/cpuinfo I see that "msr" is listed in the "flags"
> > section. So why doesn't the driver load automagically?
> > But then, at least with the version of the checker-script here, it
> > doesn't seem to make any difference, at least for whatever the script
> > tries.
> > Don't know if enabling msr will do me any good otherwise.
>
> Update:
> just checked with my laptop (Intel/Baytrail); it is the same with msr,
> module not loaded automatically, when loaded manually the contents
> of /dev/cpu/0 look just as on my AMD desktop machine. The output of the
> checker script still says "No" in the lines referring to msr.
> *BUT*, since I finally managed to compile 4.15.rc9 with gcc-7.3, the
> script claims the laptop is no longer vulnerable to "Spectre2".
> I think I'll count that as success and call it a night now :-)
>

​You could run this command:​


​djt /home/mikef # !424
grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/meltdown:Not affected
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Vulnerable: Minimal AMD
ASM retpoline


or use the checker (I assume you already are)

https://github.com/speed47/spectre-meltdown-checker

Cheers

MF




​


>
> Best regards
>
> Michael
>
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> I realize that command does have its fascination, even under
> circumstances such as these, but I neither enjoy the idea of command
> nor am I frightened of it.  It simply exists, and I will do whatever
> logically needs to be done.
> -- Spock, "The Galileo Seven", stardate 2812.7
>
>

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

[Michael Fothergill]

On 25 January 2018 at 23:28, Michael Lange  wrote:

> Hi,
>
> On Thu, 25 Jan 2018 22:23:38 +
> Michael Fothergill  wrote:
>
> > Dear All,
> >
> > I am continuing the discussion of the kernel 4.14.15 compilation in the
> > Question on CVE-2017-5754 on Debian 8.9 post in a new post.
> >
> > The reason I am running with this kernel and not the 4.15.0 rc9 kernel
> > that is now available on kernel.org is that:
> >
> > 1. It is stable
> >
> > 2. I have never tried to compile a kernel in Debian before and want to
> > make it a bit easier for me the first time would try.
> >
> > 3.  kernel 4.14.15 does have the KPTI and retpoline patches in it, so
> > it is a fair candidate for the GCC8 compiler to produce a kernel that
> > the patch checker could confirm has these meltdown and spectre fixes
> > are properly set up and active.
>
> Ok, my advice if you don't want to give up yet :-)
>

​I installed libelf-dev and did make clean.  Then I copied over the config
file and did you "Alas poor Yorick" Yes""|oldconfig
command followed by make.kpkg again and I think it worked:

 ​root@mikef-PC:/usr/src/linux-4.14.15# !498
make-kpkg
exec make kpkg_version=13.018+nmu1 -f /usr/share/kernel-package/ruleset/
minimal.mk debian
== making target debian/stamp/conf/minimal_debian [new prereqs: ]==
This is kernel package version 13.018+nmu1.
test -d debian || mkdir debian
test ! -e stamp-building || rm -f stamp-building
install -p -m 755 /usr/share/kernel-package/rules debian/rules
for file in ChangeLog  Control  Control.bin86 config templates.in rules;
do  \
cp -f  /usr/share/kernel-package/$file
./debian/;   \
done
cp: cannot stat '/usr/share/kernel-package/ChangeLog': No such file or
directory
for dir  in Config docs examples ruleset scripts pkg po;
do  \
  cp -af /usr/share/kernel-package/$dir
./debian/; \
done
test -f debian/control || sed -e 's/=V/4.14.15/g'  \
-e 's/=D/4.14.15-10.00.Custom/g' -e 's/=A/amd64/g'
\
-e 's/=SA//g'  \
-e 's/=I//g'\
-e 's/=CV/4.14/g'\
-e 's/=M/Unknown Kernel Package Maintainer
/g'\
-e 's/=ST/linux/g'  -e 's/=B/x86_64/g'\
-e 's/=R//g'/usr/share/kernel-package/Control >
debian/control
test -f debian/changelog ||  sed -e 's/=V/4.14.15/g'   \
-e 's/=D/4.14.15-10.00.Custom/g'-e 's/=A/amd64/g'
\
-e 's/=ST/linux/g' -e 's/=B/x86_64/g' \
-e 's/=M/Unknown Kernel Package Maintainer
/g'
\
 /usr/share/kernel-package/changelog > debian/changelog
chmod 0644 debian/control debian/changelog
test -d ./debian/stamp || mkdir debian/stamp
make -f debian/rules debian/stamp/conf/kernel-conf
make[1]: Entering directory '/usr/src/linux-4.14.15'
== making target debian/stamp/conf/kernel-conf [new prereqs: ]==
makeARCH=x86_64 \
oldconfig;
make[2]: Entering directory '/usr/src/linux-4.14.15'
scripts/kconfig/conf  --oldconfig Kconfig
#
# configuration written to .config
#
make[2]: Leaving directory '/usr/src/linux-4.14.15'
makeARCH=x86_64 prepare
make[2]: Entering directory '/usr/src/linux-4.14.15'
scripts/kconfig/conf  --silentoldconfig Kconfig
  SYSTBL  arch/x86/include/generated/asm/syscalls_32.h
  SYSHDR  arch/x86/include/generated/asm/unistd_32_ia32.h
  SYSHDR  arch/x86/include/generated/asm/unistd_64_x32.h
  SYSTBL  arch/x86/include/generated/asm/syscalls_64.h
  HYPERCALLS arch/x86/include/generated/asm/xen-hypercalls.h
  SYSHDR  arch/x86/include/generated/uapi/asm/unistd_32.h
  SYSHDR  arch/x86/include/generated/uapi/asm/unistd_64.h
  SYSHDR  arch/x86/include/generated/uapi/asm/unistd_x32.h
  HOSTCC  arch/x86/tools/relocs_32.o
  HOSTCC  arch/x86/tools/relocs_64.o
  HOSTCC  arch/x86/tools/relocs_common.o
  HOSTLD  arch/x86/tools/relocs
  CHK include/config/kernel.release
  UPD include/config/kernel.release
  WRAParch/x86/include/generated/asm/clkdev.h
  WRAParch/x86/include/generated/asm/dma-contiguous.h
  WRAParch/x86/include/generated/asm/early_ioremap.h
  WRAParch/x86/include/generated/asm/mcs_spinlock.h
  WRAParch/x86/include/generated/asm/mm-arch-hooks.h
  CHK include/generated/uapi/linux/version.h
  UPD include/generated/uapi/linux/version.h
  CHK include/generated/utsrelease.h
  UPD include/generated/utsrelease.h
  CC  arch/x86/purgatory/purgatory.o
  AS  arch/x86/purgatory/stack.

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

[Michael Fothergill]

When you install the kernel, the following page (
https://www.debian.org/releases/jessie/i386/ch08s06.html.en) says you must
run the following command:

*​dpkg -i ../linux-image-3.16-subarchitecture_1.0.custom_i386.deb*.

​Do I need to run mrproper beforehand?

I can't see any linux-image file in the /usr/src/4.14.15 directory:

​root@mikef-PC:/usr/src/linux-4.14.15# ls -l
total 724
drwxrwxr-x  32 root root   4096 Jan 23 18:58 arch
drwxrwxr-x   3 root root   4096 Jan 23 18:58 block
drwxrwxr-x   2 root root   4096 Jan 23 18:58 certs
-rw-rw-r--   1 root root  18693 Jan 23 18:58 COPYING
-rw-rw-r--   1 root root  98556 Jan 23 18:58 CREDITS
drwxrwxr-x   4 root root   4096 Jan 23 18:58 crypto
drwxr-xr-x  10 root root   4096 Jan 27 11:00 debian
drwxrwxr-x 121 root root  12288 Jan 23 18:58 Documentation
drwxrwxr-x 131 root root   4096 Jan 23 18:58 drivers
drwxrwxr-x   2 root root   4096 Jan 23 18:58 firmware
drwxrwxr-x  74 root root   4096 Jan 23 18:58 fs
drwxrwxr-x  29 root root   4096 Jan 25 21:13 include
drwxrwxr-x   2 root root   4096 Jan 23 18:58 init
drwxrwxr-x   2 root root   4096 Jan 23 18:58 ipc
-rw-rw-r--   1 root root   2293 Jan 23 18:58 Kbuild
-rw-rw-r--   1 root root287 Jan 23 18:58 Kconfig
drwxrwxr-x  17 root root   4096 Jan 27 11:00 kernel
drwxrwxr-x  13 root root  12288 Jan 23 18:58 lib
-rw-rw-r--   1 root root 430471 Jan 23 18:58 MAINTAINERS
-rw-rw-r--   1 root root  59978 Jan 23 18:58 Makefile
drwxrwxr-x   3 root root   4096 Jan 23 18:58 mm
drwxrwxr-x  69 root root   4096 Jan 23 18:58 net
-rw-rw-r--   1 root root722 Jan 23 18:58 README
drwxrwxr-x  28 root root   4096 Jan 23 18:58 samples
drwxrwxr-x  14 root root   4096 Jan 23 18:58 scripts
drwxrwxr-x  10 root root   4096 Jan 23 18:58 security
drwxrwxr-x  24 root root   4096 Jan 23 18:58 sound
drwxrwxr-x  30 root root   4096 Jan 23 18:58 tools
drwxrwxr-x   2 root root   4096 Jan 23 18:58 usr
drwxrwxr-x   4 root root   4096 Jan 23 18:58 virt
root@mikef-PC:/usr/src/linux-4.14.15#

Where would the default location of such a file be if were created using
the make-kpkg command?

Cheers

MF

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

[Michael Fothergill]

On 27 January 2018 at 11:26, Michael Fothergill <
michael.fotherg...@gmail.com> wrote:

> When you install the kernel, the following page (
> https://www.debian.org/releases/jessie/i386/ch08s06.html.en) says you
> must run the following command:
>
> *​dpkg -i ../linux-image-3.16-subarchitecture_1.0.custom_i386.deb*.
>
> ​Do I need to run mrproper beforehand?
>
> I can't see any linux-image file in the /usr/src/4.14.15 directory:
>
> ​root@mikef-PC:/usr/src/linux-4.14.15# ls -l
> total 724
> drwxrwxr-x  32 root root   4096 Jan 23 18:58 arch
> drwxrwxr-x   3 root root   4096 Jan 23 18:58 block
> drwxrwxr-x   2 root root   4096 Jan 23 18:58 certs
> -rw-rw-r--   1 root root  18693 Jan 23 18:58 COPYING
> -rw-rw-r--   1 root root  98556 Jan 23 18:58 CREDITS
> drwxrwxr-x   4 root root   4096 Jan 23 18:58 crypto
> drwxr-xr-x  10 root root   4096 Jan 27 11:00 debian
> drwxrwxr-x 121 root root  12288 Jan 23 18:58 Documentation
> drwxrwxr-x 131 root root   4096 Jan 23 18:58 drivers
> drwxrwxr-x   2 root root   4096 Jan 23 18:58 firmware
> drwxrwxr-x  74 root root   4096 Jan 23 18:58 fs
> drwxrwxr-x  29 root root   4096 Jan 25 21:13 include
> drwxrwxr-x   2 root root   4096 Jan 23 18:58 init
> drwxrwxr-x   2 root root   4096 Jan 23 18:58 ipc
> -rw-rw-r--   1 root root   2293 Jan 23 18:58 Kbuild
> -rw-rw-r--   1 root root287 Jan 23 18:58 Kconfig
> drwxrwxr-x  17 root root   4096 Jan 27 11:00 kernel
> drwxrwxr-x  13 root root  12288 Jan 23 18:58 lib
> -rw-rw-r--   1 root root 430471 Jan 23 18:58 MAINTAINERS
> -rw-rw-r--   1 root root  59978 Jan 23 18:58 Makefile
> drwxrwxr-x   3 root root   4096 Jan 23 18:58 mm
> drwxrwxr-x  69 root root   4096 Jan 23 18:58 net
> -rw-rw-r--   1 root root722 Jan 23 18:58 README
> drwxrwxr-x  28 root root   4096 Jan 23 18:58 samples
> drwxrwxr-x  14 root root   4096 Jan 23 18:58 scripts
> drwxrwxr-x  10 root root   4096 Jan 23 18:58 security
> drwxrwxr-x  24 root root   4096 Jan 23 18:58 sound
> drwxrwxr-x  30 root root   4096 Jan 23 18:58 tools
> drwxrwxr-x   2 root root   4096 Jan 23 18:58 usr
> drwxrwxr-x   4 root root   4096 Jan 23 18:58 virt
> root@mikef-PC:/usr/src/linux-4.14.15#
>
> Where would the default location of such a file be if were created using
> the make-kpkg command?
>
> Cheers
>


> MF
>
>
​PS since I can't seem to find the linux-image file for the new kernel to
run dpkg -i on
should I have run the ​





*fakeroot make-kpkg --initrd --revision=1.0.custom kernel_imag​e ie
fakeroot make-kpkg --initrd --revision=4.14.15.krankenhaus kernel_imag​e *
​command instead of just make-kpkg to create it?

Cheers





​

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

[Michael Fothergill]

On 27 January 2018 at 11:59, Michael Lange  wrote:

> Hi,
>
> On Sat, 27 Jan 2018 11:26:25 +
> Michael Fothergill  wrote:
>
> >
> > Where would the default location of such a file be if were created using
> > the make-kpkg command?
>
> the package should be in the source's parent directory, in your case I
> guess in /usr/src .
>

​Many thanks for the help again here.  I can't see it in /usr/src:​


root@mikef-PC:/usr/src# ls -l
total 907316
drwxrwxr-x 26 root  root   4096 Jan 27 11:01 linux-4.14.15
-rw-r--r--  1 mikef mikef 825139200 Jan 25 16:43 linux-4.14.15.tar
drwxr-xr-x  2 root  root   4096 Jan 25 18:02 linux-config-4.14
drwxr-xr-x  4 root  root   4096 Jan 25 00:01
linux-headers-4.14.0-3-amd64
drwxr-xr-x  4 root  root   4096 Jan 25 00:01
linux-headers-4.14.0-3-common
drwxr-xr-x  4 root  root   4096 Jan 24 16:32 linux-headers-4.9.0-4-amd64
drwxr-xr-x  4 root  root   4096 Jan 24 16:33
linux-headers-4.9.0-4-common
lrwxrwxrwx  1 root  root 24 Jan 14 19:45 linux-kbuild-4.14 ->
../lib/linux-kbuild-4.14
lrwxrwxrwx  1 root  root 24 Jan 15 04:43 linux-kbuild-4.15 ->
../lib/linux-kbuild-4.15
lrwxrwxrwx  1 root  root 23 Aug  6 05:24 linux-kbuild-4.9 ->
../lib/linux-kbuild-4.9
-rw-r--r--  1 root  root 216052 Jan 14 19:45
linux-patch-4.14-rt.patch.xz
-rw-r--r--  1 root  root  103701828 Jan 14 19:45 linux-source-4.14.tar.xz
drwxr-xr-x  8 root  root   4096 Nov 18 09:15 open-vm-tools-10.1.5
root@mikef-PC:/usr/src#


​Should the filename be something like linux-image-4.14.14.deb etc?

Maybe Greg could think some find command that would search everywhere in
the install I have here and then find it in some funny directory (even
/tmp?) no one has ever heard of.

I would be grateful for suggestions here.

Could there be a bug in gcc 8 that made it forget to actually output the
file?

Thanks

MF​




>
> Regards
>
> Michael
>
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> Vulcans never bluff.
> -- Spock, "The Doomsday Machine", stardate 4202.1
>
>

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

[Michael Fothergill]

On 27 January 2018 at 12:12, Michael Fothergill <
michael.fotherg...@gmail.com> wrote:

>
>
> On 27 January 2018 at 11:59, Michael Lange  wrote:
>
>> Hi,
>>
>> On Sat, 27 Jan 2018 11:26:25 +
>> Michael Fothergill  wrote:
>>
>> >
>> > Where would the default location of such a file be if were created using
>> > the make-kpkg command?
>>
>> the package should be in the source's parent directory, in your case I
>> guess in /usr/src .
>>
>
> ​Many thanks for the help again here.  I can't see it in /usr/src:​
>
>
> root@mikef-PC:/usr/src# ls -l
> total 907316
> drwxrwxr-x 26 root  root   4096 Jan 27 11:01 linux-4.14.15
> -rw-r--r--  1 mikef mikef 825139200 Jan 25 16:43 linux-4.14.15.tar
> drwxr-xr-x  2 root  root   4096 Jan 25 18:02 linux-config-4.14
> drwxr-xr-x  4 root  root   4096 Jan 25 00:01
> linux-headers-4.14.0-3-amd64
> drwxr-xr-x  4 root  root   4096 Jan 25 00:01
> linux-headers-4.14.0-3-common
> drwxr-xr-x  4 root  root   4096 Jan 24 16:32
> linux-headers-4.9.0-4-amd64
> drwxr-xr-x  4 root  root   4096 Jan 24 16:33
> linux-headers-4.9.0-4-common
> lrwxrwxrwx  1 root  root 24 Jan 14 19:45 linux-kbuild-4.14 ->
> ../lib/linux-kbuild-4.14
> lrwxrwxrwx  1 root  root 24 Jan 15 04:43 linux-kbuild-4.15 ->
> ../lib/linux-kbuild-4.15
> lrwxrwxrwx  1 root  root 23 Aug  6 05:24 linux-kbuild-4.9 ->
> ../lib/linux-kbuild-4.9
> -rw-r--r--  1 root  root 216052 Jan 14 19:45
> linux-patch-4.14-rt.patch.xz
> -rw-r--r--  1 root  root  103701828 Jan 14 19:45 linux-source-4.14.tar.xz
> drwxr-xr-x  8 root  root   4096 Nov 18 09:15 open-vm-tools-10.1.5
> root@mikef-PC:/usr/src#
>
>
> ​Should the filename be something like linux-image-4.14.14.deb etc?
>
> Maybe Greg could think some find command that would search everywhere in
> the install I have here and then find it in some funny directory (even
> /tmp?) no one has ever heard of.
>
> I would be grateful for suggestions here.
>
> Could there be a bug in gcc 8 that made it forget to actually output the
> file?
>
> Thanks
>
> MF​
>

​Available space for the file creation does not seem to be a problem:

​
 root@mikef-PC:/usr/src# df
Filesystem 1K-blocks Used Available Use% Mounted on
udev 35157160   3515716   0% /dev
tmpfs 71418017564696616   3% /run
/dev/sda9  352522356 17476768 317115400   6% /
tmpfs357088488304   3482580   3% /dev/shm
tmpfs   51204  5116   1% /run/lock
tmpfs35708840   3570884   0% /sys/fs/cgroup
tmpfs 714176   12714164   1% /run/user/1000
root@mikef-PC:/usr/src#

​MF​



>
>
>
>>
>> Regards
>>
>> Michael
>>
>>
>> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>>
>> Vulcans never bluff.
>> -- Spock, "The Doomsday Machine", stardate 4202.1
>>
>>
>

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

[Michael Fothergill]

On 27 January 2018 at 11:59, Michael Lange  wrote:

> Hi,
>
> On Sat, 27 Jan 2018 11:26:25 +
> Michael Fothergill  wrote:
>
> >
> > Where would the default location of such a file be if were created using
> > the make-kpkg command?
>
> the package should be in the source's parent directory, in your case I
> guess in /usr/src .
>

​I think something is not right here. The compilation was very quick.
Normally in gentoo the kernel compilation takes a little while.
Maybe something got left out.

Maybe I should have run mrproper after make clean before running make-kpkg.

Cheers

MF​


>
> Regards
>
> Michael
>
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> Vulcans never bluff.
> -- Spock, "The Doomsday Machine", stardate 4202.1
>
>

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

[Michael Fothergill]

On 27 January 2018 at 12:43, Michael Lange  wrote:

> Hi,
>
> On Sat, 27 Jan 2018 12:12:57 +
> Michael Fothergill  wrote:
>
> >
> > ​Should the filename be something like linux-image-4.14.14.deb etc?
>
> With default settings for make-kpkg the filename is probably a little
> longer, here it looks like
>
> linux-image-4.15.0-rc9-klappnase270118_4.15.0-rc9-
> klappnase270118-10.00.Custom_amd64.deb
>
>
> >
> > Maybe Greg could think some find command that would search everywhere in
> > the install I have here and then find it in some funny directory (even
> > /tmp?) no one has ever heard of.
> >
> > I would be grateful for suggestions here.
> >
> > Could there be a bug in gcc 8 that made it forget to actually output the
> > file?
>
> I don't think that gcc is to blame. Did you look at the final messages
> make-kpkg printed? If run successfully it should say something like
> "building package linux-image-..." .
>

​It never did it.   It did this at the end:​


chmod 0644 debian/control debian/changelog
make -f debian/rules debian/stamp/conf/kernel-conf
make[2]: Entering directory '/usr/src/linux-4.14.15'
make[2]: 'debian/stamp/conf/kernel-conf' is up to date.
make[2]: Leaving directory '/usr/src/linux-4.14.15'
make[1]: Leaving directory '/usr/src/linux-4.14.15'
echo done > debian/stamp/conf/minimal_debian
exec debian/rules
nothing to be done.

​and stopped.

if you look through the rest of the output I posted above its not there
AFAICT.

Cheers

MF​



> Regards
>
> Michael
>
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> Power is danger.
> -- The Centurion, "Balance of Terror", stardate 1709.2
>
>

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

[Michael Fothergill]

It does seem as if make-kpkg has gone awol here.

MF

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

[Michael Fothergill]

On 27 January 2018 at 12:43, Michael Lange  wrote:

> Hi,
>
> On Sat, 27 Jan 2018 12:12:57 +
> Michael Fothergill  wrote:
>
> >
> > ​Should the filename be something like linux-image-4.14.14.deb etc?
>
> With default settings for make-kpkg the filename is probably a little
> longer, here it looks like
>
> linux-image-4.15.0-rc9-klappnase270118_4.15.0-rc9-
> klappnase270118-10.00.Custom_amd64.deb
>
>
> >
> > Maybe Greg could think some find command that would search everywhere in
> > the install I have here and then find it in some funny directory (even
> > /tmp?) no one has ever heard of.
> >
> > I would be grateful for suggestions here.
> >
> > Could there be a bug in gcc 8 that made it forget to actually output the
> > file?
>
> I don't think that gcc is to blame.


​I think I will sign up on the gcc gnu help page and ask people if they
have a test case file I can run to 100% confirm the GCC 8 compiler is
running properly.​
​Once I am convinced it is then the next stage is to try to talk to the
developers who maintain the make-kpkg program.

Cheers

MF​




> Did you look at the final messages
> make-kpkg printed? If run successfully it should say something like
> "building package linux-image-..." .
>
> Regards
>
> Michael
>

​​



>
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> Power is danger.
> -- The Centurion, "Balance of Terror", stardate 1709.2
>
>

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

[Michael Fothergill]

On 27 January 2018 at 13:17, Michael Lange  wrote:

> On Sat, 27 Jan 2018 12:32:24 +
> Michael Fothergill  wrote:
>
> > On 27 January 2018 at 11:59, Michael Lange  wrote:
> >
> > > Hi,
> > >
> > > On Sat, 27 Jan 2018 11:26:25 +
> > > Michael Fothergill  wrote:
> > >
> > > >
> > > > Where would the default location of such a file be if were created
> > > > using the make-kpkg command?
> > >
> > > the package should be in the source's parent directory, in your case I
> > > guess in /usr/src .
> > >
> >
> > ​I think something is not right here. The compilation was very quick.
> > Normally in gentoo the kernel compilation takes a little while.
> > Maybe something got left out.
> >
> > Maybe I should have run mrproper after make clean before running
> > make-kpkg.
>
> Yes, I naturally cannot tell from here, but it sounds like for some
> reason the procedure was terminated prematurely.
>

​But, you would argue that what terminated was the make-kpkg efforts to
make use of the result of the successful compilation not a malfunction of
the compiler itself

At least I think that is what you are saying/suggesting here.

It did occur to me that maybe I still need some extra package to be
installed either for the compiler or make-kpkg here.

Cheers

MF​



>
> Regards
>
> Michael
>
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> It is necessary to have purpose.
> -- Alice #1, "I, Mudd", stardate 4513.3
>
>

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

[Michael Fothergill]

On 27 January 2018 at 13:38, Michael Lange  wrote:

> Hi,
>
> On Sat, 27 Jan 2018 13:12:13 +
> Michael Fothergill  wrote:
>
> > ​I think I will sign up on the gcc gnu help page and ask people if they
> > have a test case file I can run to 100% confirm the GCC 8 compiler is
> > running properly.​
> > ​Once I am convinced it is then the next stage is to try to talk to the
> > developers who maintain the make-kpkg program.
>
> are you still using gcc-8? Here this one didn't work at all for me,
> compiling always aborted early with compiler errors. It worked
> immediately though after I removed ggc-8 and upgraded gcc-7 to v. 7.3
> from sid.
>

​In my case after I took you helpful advice and installed libelf-dev in GCC
8 (which I am still using)  the crash I had went away.
​
I think now GCC 8 is close to working OK.

Perhaps it needs another little nudge or some other package we don't know
about.

I have sent the gnu gcc help people the following email:

**

Dear All,

I am running debian unstable on an amd64 kaveri box.

I recently installed GCC 8 from the Debian experimental site:

https://packages.debian.org/experimental/devel/gcc-8

I also installed libelf-dev.

It did run correctly without it.

I have been using it to try to compile and install linux kernel 4.14.15
using the
debian package make-kpkg.

The output from doing this is here:

https://pastebin.com/sgrhdCKW

I copied over the config file from/boot and ran make-clean and the
command:  yes "" | make oldconfig before running make-kpkg.

Kernel compilations I do in gentoo usually take a while.

This ran too quickly I think.

Something is not quite right here.

Perhaps some more depedent packages needed to be installed to make GCC8 run
happily.

Do you have a test file I can compile that will check whether GCC 8 is
really running correctly?

The discussions on these two threads are relevant:

https://lists.debian.org/debian-user/2018/01/msg01159.html

https://lists.debian.org/debian-user/2018/01/msg01002.html

We are all trying to compile kernels that defeat the meltdown and spectre
vulnerabilities.

Comments appreciated.

Regards

​MF​



Maybe they can help here.

Cheers

MF



>
> Regards
>
> Michael
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> "It's hard to believe that something which is neither seen nor
> felt can do so much harm."
> "That's true.  But an idea can't be seen or felt.  And that's
> what kept the Troglytes in the mines all these centuries.  A mistaken
> idea."
> -- Vanna and Kirk, "The Cloud Minders", stardate 5819.0
>
>

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

[Michael Fothergill]

On 27 January 2018 at 13:38, Michael Lange  wrote:

> Hi,
>
> On Sat, 27 Jan 2018 13:12:13 +
> Michael Fothergill  wrote:
>
> > ​I think I will sign up on the gcc gnu help page and ask people if they
> > have a test case file I can run to 100% confirm the GCC 8 compiler is
> > running properly.​
> > ​Once I am convinced it is then the next stage is to try to talk to the
> > developers who maintain the make-kpkg program.
>
> are you still using gcc-8? Here this one didn't work at all for me,
> compiling always aborted early with compiler errors. It worked
> immediately though after I removed ggc-8 and upgraded gcc-7 to v. 7.3
> from sid.
>
> Regards
>
>
> Michael
>

​PS The maintainer of  ​
 kernel-package
​ (https://tracker.debian.org/pkg/kernel-package) that contains make-kpkg
is: ​Manoj Srivastava  .

Cheers

MF



> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> "It's hard to believe that something which is neither seen nor
> felt can do so much harm."
> "That's true.  But an idea can't be seen or felt.  And that's
> what kept the Troglytes in the mines all these centuries.  A mistaken
> idea."
> -- Vanna and Kirk, "The Cloud Minders", stardate 5819.0
>
>

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

[Michael Fothergill]

On 27 January 2018 at 13:38, Michael Lange  wrote:

> Hi,
>
> On Sat, 27 Jan 2018 13:12:13 +
> Michael Fothergill  wrote:
>
> > ​I think I will sign up on the gcc gnu help page and ask people if they
> > have a test case file I can run to 100% confirm the GCC 8 compiler is
> > running properly.​
> > ​Once I am convinced it is then the next stage is to try to talk to the
> > developers who maintain the make-kpkg program.
>
> are you still using gcc-8? Here this one didn't work at all for me,
> compiling always aborted early with compiler errors. It worked
> immediately though after I removed ggc-8 and upgraded gcc-7 to v. 7.3
> from sid.
>
> Regards
>
> Michael
>

​I have sent the kernel-source package maintainer the following email:

**

Dear Sir,

I understand that you are the package maintainer for kernel-source ie
make-kpkg etc. within debian.

I am running debian unstable (Sid)on an amd64 kaveri box.

I installed GCC 8 from the experimental repository.  I am trying to use it
to compile the kernel 4.14.15 using make-kpkg to use the fixes for the
meltdown and spectre vulnerabilities.

The output from doing this is here:

https://pastebin.com/sgrhdCKW

Make-kpkg did not create any linux-image file ..?!

I copied over the config file from/boot and ran make-clean and the
command:  yes "" | make oldconfig before running make-kpkg.

Kernel compilations I do in gentoo (I am a gentoo user as well as a debian
user) usually take a while.

This ran too quickly I think.

Something is not quite right here I think.

It might be that more dependent packages needed to be installed to make
GCC8 run happily.

As a result I have sent an email to the gnu gcc help site (
gcc-h...@gcc.gnu.org) asking them for a test file to check that GCC8 is
running correctly.

But, maybe you might say that make-kpkg needs to be upgraded in some way to
work correctly here and GCC 8 ran OK...


The discussions on these two threads are relevant to this case:

https://lists.debian.org/debian-user/2018/01/msg01159.html

https://lists.debian.org/debian-user/2018/01/msg01002.html

We are all trying to compile kernels that defeat the meltdown and spectre
vulnerabilities.

Comments appreciated.

Regards
​
etc

*

Maybe will end up having to quit with GCC8 but it I am giving it one last
attempt here.

Cheers

MF




>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> "It's hard to believe that something which is neither seen nor
> felt can do so much harm."
> "That's true.  But an idea can't be seen or felt.  And that's
> what kept the Troglytes in the mines all these centuries.  A mistaken
> idea."
> -- Vanna and Kirk, "The Cloud Minders", stardate 5819.0
>
>

Re: Kernel for Spectre and Meltdown

[Michael Fothergill]

On 29 January 2018 at 07:52, Dextin Jerafmel  wrote:

> Hello
>
> I've installed Debian 9.3 about one and a half month ago . I'm newbie to
> Linux world
> My Kernel was 4.9.0.3 at the first of installation . After upgrading (
> sudo apt upgrade ) it becomes 4.9.0.4
> But in Your site You've mentioned Kernel for Debian Stretch is 4.9.65 and
> You updated it for Spectre and Meltdown bugs
> I tried to search for available Kernel images but there isn't any newer
> Kernel than 4.9.0.5
>
> Please guide me
>

​Your need to upgrade to unstable (Debian Sid).  Then you need to get the
latest kernel from the kernel.org website.
You also need to install GCC7 in sid which will give you version 7.3.0 at
present.  That is a new enough compiler to be able to properly install the
spectre and meltdown fixes.
Then you need to run the spectre/meltdown checker which you can get from a
github site and run locally on your box to know it's really installed
properly.
AFAICT at present running a kernel with spectre and meltdown protection
means running debian in the opposite way it is usually billed as to the
outside world ie unstable for quite some time.

Eventually gcc 7.3 could become available in buster/testing but I don't
know when.

I think gentoo is  a good distribution to try in the current security
vulnerability situation.  It is good for kernel compilations and
modifications etc.

Running gcc 7.3 is as easy in gentoo stable is it is gentoo testing.  The
ebuild is there now and the latest version binunits (2.30) is getting
readied.  I have installed
gcc 7.3 on it and soon I will uprade the kernel shortly.  New kernels are
in the pipeline that will have more spectre fixes added.

I will fire them all in to my gentoo  install soon like a deck of cards.

Cheers

Regards

Michael Fothergill



​


>
> Thanks a lot
>
>

Re: Kernel for Spectre and Meltdown

[Michael Fothergill]

On 29 January 2018 at 10:10, deloptes  wrote:

> Michael Fothergill wrote:
>
> > Your need to upgrade to unstable (Debian Sid).  Then you need to get the
> > latest kernel from the kernel.org website.
>
> worst BS ever seen - DON'T LISTEN TO THIS PLEASE
>
> Michael, please stop writing such things in public
>

​I accept that are some kernels that you could run in stable apparently
that address the security issue etc.
I apologise for inaccuracy there.
But perhaps not all of what I posted is BS.

Cheers

MF​


>
> regards
>
>

Re: Kernel for Spectre and Meltdown

[Michael Fothergill]

On 29 January 2018 at 10:17, Michael Lange  wrote:

> Hi,
>
> On Mon, 29 Jan 2018 08:35:58 +
> Michael Fothergill  wrote:
>
> > ​Your need to upgrade to unstable (Debian Sid).  Then you need to get
> > the latest kernel from the kernel.org website.
> > You also need to install GCC7 in sid which will give you version 7.3.0
> > at present.  That is a new enough compiler to be able to properly
> > install the spectre and meltdown fixes.
>
> The "meltdown fix" (a.k.a. page tables isolation) is already included in
> Stretch's 4.9 kernel.
>

​Yes, that is true.  If the OP was running an Intel box than that really
would be useful to them.
So I should have mentioned it to them.  But, to be fair the OP specifically
mentioned that
they were interested in fixes to the meltdown and spectre vulnerabilities
ie both problems not just one of them.


Cheers

MF
​


>
> > Then you need to run the spectre/meltdown checker which you can get
> > from a github site and run locally on your box to know it's really
> > installed properly.
> > AFAICT at present running a kernel with spectre and meltdown protection
> > means running debian in the opposite way it is usually billed as to the
> > outside world ie unstable for quite some time.
>
> That's not entirely true, you can run Debian Stable / Stretch with a
> kernel that was compiled on Sid with gcc-7.3, however it is true that for
> now there is no such kernel available for Stretch out-of-the-box and even
> installing the latest gcc-7 compiler packages from sid on a Stretch
> system is, if possible at all, probably not trivial.
>
> I assume that most likely someone is working on an update to gcc-6 that
> will make it possible to compile the latest "spectre fix" into the kernel
> with Stretch's default compiler and we will have to wait until that is
> done.
>
> I think it is likely though, that a kernel with that fix will be
> available soon in the "experimental" suite and could be installed
> manually on Stretch.
>
> Regards
>
> Michael
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> After a time, you may find that "having" is not so pleasing a thing,
> after all, as "wanting."  It is not logical, but it is often true.
> -- Spock, "Amok Time", stardate 3372.7
>
>

Re: Kernel for Spectre and Meltdown

[Michael Fothergill]

On 29 January 2018 at 10:17, Michael Lange  wrote:

> Hi,
>
> On Mon, 29 Jan 2018 08:35:58 +
> Michael Fothergill  wrote:
>
> > ​Your need to upgrade to unstable (Debian Sid).  Then you need to get
> > the latest kernel from the kernel.org website.
> > You also need to install GCC7 in sid which will give you version 7.3.0
> > at present.  That is a new enough compiler to be able to properly
> > install the spectre and meltdown fixes.
>
> The "meltdown fix" (a.k.a. page tables isolation) is already included in
> Stretch's 4.9 kernel.
>
> > Then you need to run the spectre/meltdown checker which you can get
> > from a github site and run locally on your box to know it's really
> > installed properly.
> > AFAICT at present running a kernel with spectre and meltdown protection
> > means running debian in the opposite way it is usually billed as to the
> > outside world ie unstable for quite some time.
>
> That's not entirely true, you can run Debian Stable / Stretch with a
> kernel that was compiled on Sid with gcc-7.3, however it is true that for
> now there is no such kernel available for Stretch out-of-the-box and even
> installing the latest gcc-7 compiler packages from sid on a Stretch
> system is, if possible at all, probably not trivial.
>

​That is pretty much what I had been led to believe already except
for the part where you suggest that a kernel compiled in Sid could
apparently
be used in stable.  Again, if that would be true I should have mentioned it
to the OP; sorry about that.
Apart from that it makes me think that what I posted was perhaps not BS
after all...

Cheers

MF​



>
> I assume that most likely someone is working on an update to gcc-6 that
> will make it possible to compile the latest "spectre fix" into the kernel
> with Stretch's default compiler and we will have to wait until that is
> done.
>
> I think it is likely though, that a kernel with that fix will be
> available soon in the "experimental" suite and could be installed
> manually on Stretch.
>

​



>
> Regards
>
> Michael
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> After a time, you may find that "having" is not so pleasing a thing,
> after all, as "wanting."  It is not logical, but it is often true.
> -- Spock, "Amok Time", stardate 3372.7
>
>

Re: Kernel for Spectre and Meltdown

[Michael Fothergill]

On 29 January 2018 at 13:26,  wrote:

> On Monday, January 29, 2018 06:22:50 AM Michael Fothergill wrote:
> > ​I accept that are some kernels that you could run in stable apparently
> > that address the security issue etc.
>

​Do they work on spectre as well as meltdown?
Sorry for not replying on the site by mistake.

Regards

MF​



>
> I'd go a step further--it's not some (random) kernels that you could run,
> but
> it is the updated kernels (now, and unless a regression, going forward)
> that
> will have the fix(es) and will run "automatically" (perhaps after a
> reboot).
>
>
>

Re: Kernel for Spectre and Meltdown

[Michael Fothergill]

On 29 January 2018 at 13:28, deloptes  wrote:

> Michael Fothergill wrote:
>
> > I accept that are some kernels that you could run in stable apparently
> > that address the security issue etc.
> > I apologise for inaccuracy there.
> > But perhaps not all of what I posted is BS.
>
> You can run any kernel in stable
>
> I just build 4.14
>
> make oldconfig
> make -j4 deb-pkg
>
> what has gcc7 to do with the patches is unclear to me, but I admit I have
> never worried about.
>

​I thought you had to have gcc7 because it included a backport of some code
used in GCC 8 that was needed to allow e.g. the spectre fix to work
properly.

If you could use any compiler to do it then earlier my post truly would be
BS.​


​Cheers

MF​

>
> My conclusion to this Spectre and Meltdown hysteria is, that a single
> machine in a secure environment is not exactly endangered.
> People should better take care of their mobile devices, especially phones
> and tablets, where you need neither Spectre nor Meltdown to compromise.
>
> regards
>
>

Re: Kernel for Spectre and Meltdown

[Michael Fothergill]

On 29 January 2018 at 13:35, Michael Fothergill <
michael.fotherg...@gmail.com> wrote:

>
>
> On 29 January 2018 at 13:28, deloptes  wrote:
>
>> Michael Fothergill wrote:
>>
>> > I accept that are some kernels that you could run in stable apparently
>> > that address the security issue etc.
>> > I apologise for inaccuracy there.
>> > But perhaps not all of what I posted is BS.
>>
>> You can run any kernel in stable
>>
>> I just build 4.14
>>
>> make oldconfig
>> make -j4 deb-pkg
>>
>> what has gcc7 to do with the patches is unclear to me, but I admit I have
>> never worried about.
>>
>
> ​I thought you had to have gcc7 because it included a backport of some
> code used in GCC 8 that was needed to allow e.g. the spectre fix to work
> properly.
>
> If you could use any compiler to do it then earlier my post truly would be
> BS.​
>

PS as I understand (correct me if I am wrong)  the compiler needs to be GCC
7.3.0 or greater (I believe the 7.2 rc2 also works); if you used a compiler
earlier that you would get a kernel that works OK in very respect except
the for spectre fix itself.

The spectre-meltdown checker  if you ran it (as I did in gentoo with the
7.2.1 compiler or whatever it was) said that the compiler I used was not
capable of properly installing the spectre fix so it was not enabled.

GCC 7.3.0 is now available in Debian sid.

Cheers

MF  ​


>
>
> ​Cheers
>
> MF​
>
>>
>> My conclusion to this Spectre and Meltdown hysteria is, that a single
>> machine in a secure environment is not exactly endangered.
>> People should better take care of their mobile devices, especially phones
>> and tablets, where you need neither Spectre nor Meltdown to compromise.
>>
>> regards
>>
>>
>

Re: Kernel for Spectre and Meltdown

[Michael Fothergill]

On 29 January 2018 at 12:49, Michael Fothergill <
michael.fotherg...@gmail.com> wrote:

>
>
> On 29 January 2018 at 10:17, Michael Lange  wrote:
>
>> Hi,
>>
>> On Mon, 29 Jan 2018 08:35:58 +
>> Michael Fothergill  wrote:
>>
>> > ​Your need to upgrade to unstable (Debian Sid).  Then you need to get
>> > the latest kernel from the kernel.org website.
>> > You also need to install GCC7 in sid which will give you version 7.3.0
>> > at present.  That is a new enough compiler to be able to properly
>> > install the spectre and meltdown fixes.
>>
>> The "meltdown fix" (a.k.a. page tables isolation) is already included in
>> Stretch's 4.9 kernel.
>>
>> > Then you need to run the spectre/meltdown checker which you can get
>> > from a github site and run locally on your box to know it's really
>> > installed properly.
>> > AFAICT at present running a kernel with spectre and meltdown protection
>> > means running debian in the opposite way it is usually billed as to the
>> > outside world ie unstable for quite some time.
>>
>> That's not entirely true, you can run Debian Stable / Stretch with a
>> kernel that was compiled on Sid with gcc-7.3, however it is true that for
>> now there is no such kernel available for Stretch out-of-the-box and even
>> installing the latest gcc-7 compiler packages from sid on a Stretch
>> system is, if possible at all, probably not trivial.
>>
>
​In the recent MVE thread , I had asked if I could compile the spectre fix
kernel in Sid and move to buster (I thought moving down to
stretch would likely not be practical).

The response from Greg was the following:

On Thu, Jan 25, 2018 at 12:36:46PM +, Michael Fothergill wrote:
> ​If I become sid and install the kernel correctly, could I go back to
being
> just buster (sounds like an energy drink) and carry on using the new
kernel?

No.

***

At that point I really did seem that:

1. I had no choice but to become sid/unstable here.

​2. I would have to remain being sid for some considerable time running
this new fangled kernel.

And so would  anyone else trying to address the spectre problem including
new users, as far as I could then.

I was interested specifically in the spectre fix because as an AMD user
meltdown is not a vulnerability for me which the spectre-meltdown-checker
reminds you
of when you run it.

I then put up a post saying "well I guess I am going to have to upgrade to
sid then" or something similar.

The silence was deafening.

So I went ahead and installed GCC 8 (because GCC 7.3 hadn't quite been
ported into sid at that point) and tried to compile ​the new spectre fix
kernel.

​I now see that maybe the kernel could be more portable once created than
it seemed then to me. as has been pointed out above that the OP really
ought to have
been made aware of.

Cheers

MF​



>
> ​That is pretty much what I had been led to believe already except
> for the part where you suggest that a kernel compiled in Sid could
> apparently
> be used in stable.  Again, if that would be true I should have mentioned
> it to the OP; sorry about that.
> Apart from that it makes me think that what I posted was perhaps not BS
> after all...
>
> Cheers
>
> MF​
>
>
>
>>
>> I assume that most likely someone is working on an update to gcc-6 that
>> will make it possible to compile the latest "spectre fix" into the kernel
>> with Stretch's default compiler and we will have to wait until that is
>> done.
>>
>> I think it is likely though, that a kernel with that fix will be
>> available soon in the "experimental" suite and could be installed
>> manually on Stretch.
>>
>
> ​
>
>
>
>>
>> Regards
>>
>> Michael
>>
>> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>>
>> After a time, you may find that "having" is not so pleasing a thing,
>> after all, as "wanting."  It is not logical, but it is often true.
>> -- Spock, "Amok Time", stardate 3372.7
>>
>>
>

Re: Kernel for Spectre and Meltdown

[Michael Fothergill]

On 30 January 2018 at 15:23, Elimar Riesebieter  wrote:

> * rhkra...@gmail.com  [2018-01-29 10:47 -0500]:
>
> [...]
> > On the other hand, if I download kernel source, I would need GCC, and a
> > version that is sufficient for the code.
>
> One can check the compiler version the running kernel is built with
> by:
>
> $ cat /proc/version
> Linux version 4.14.15-toy-lxtec-amd64 (riesebie@toy) (gcc version 7.3.0
> (Debian 7.3.0-1)) #1 SMP Tue Jan 30 14:20:49 CET 2018
>

​That is a very useful command.

I ran it myself.

djt /home/mikef/spectre-meltdown-checker # cat /proc/version
Linux version 4.14.14-gentoo (root@djt) (gcc version 7.2.0 (Gentoo
7.2.0-r1)) #1 SMP Tue Jan 23 13:06:23 GMT 2018

Here is a bit of the output from the spectre patch checker:


​* Mitigation 2
  * Kernel compiled with retpoline option:  YES
  * Kernel compiled with a retpoline-aware compiler:  NO  (kernel reports
minimal retpoline compilation)
  * Retpoline enabled:  YES
> STATUS:  VULNERABLE  (Vulnerable: Minimal AMD ASM retpoline)

​As can be seen here, the compiler I used to create this kernel was not
recent enough to make retpoline work.

Since I now have gcc 7.3 installed I will do kernel upgrade in a little
while and see if I can change the NO in

  "* Kernel compiled with a retpoline-aware compiler:  NO  (kernel reports
minimal retpoline compilation)"

to YES.

I think it will work.

Cheers MF




​






>
> ^
>
> Elimar
> --
>   You cannot propel yourself forward by
>   patting yourself on the back.
>
>

Re: Kernel for Spectre and Meltdown

[Michael Fothergill]

On 30 January 2018 at 16:02, Michael Fothergill <
michael.fotherg...@gmail.com> wrote:

>
>
> On 30 January 2018 at 15:23, Elimar Riesebieter  wrote:
>
>> * rhkra...@gmail.com  [2018-01-29 10:47 -0500]:
>>
>> [...]
>> > On the other hand, if I download kernel source, I would need GCC, and a
>> > version that is sufficient for the code.
>>
>> One can check the compiler version the running kernel is built with
>> by:
>>
>> $ cat /proc/version
>> Linux version 4.14.15-toy-lxtec-amd64 (riesebie@toy) (gcc version 7.3.0
>> (Debian 7.3.0-1)) #1 SMP Tue Jan 30 14:20:49 CET 2018
>>
>
> ​That is a very useful command.
>
> I ran it myself.
>
> djt /home/mikef/spectre-meltdown-checker # cat /proc/version
> Linux version 4.14.14-gentoo (root@djt) (gcc version 7.2.0 (Gentoo
> 7.2.0-r1)) #1 SMP Tue Jan 23 13:06:23 GMT 2018
>
> Here is a bit of the output from the spectre patch checker:
>
>
> ​* Mitigation 2
>   * Kernel compiled with retpoline option:  YES
>   * Kernel compiled with a retpoline-aware compiler:  NO  (kernel reports
> minimal retpoline compilation)
>   * Retpoline enabled:  YES
> > STATUS:  VULNERABLE  (Vulnerable: Minimal AMD ASM retpoline)
>
> ​As can be seen here, the compiler I used to create this kernel was not
> recent enough to make retpoline work.
>
> Since I now have gcc 7.3 installed I will do kernel upgrade in a little
> while and see if I can change the NO in
>
>   "* Kernel compiled with a retpoline-aware compiler:  NO  (kernel reports
> minimal retpoline compilation)"
>
> to YES.
>
> I think it will work.
>
> Cheers MF
>

​I just ran the kernel rebuild:

djt /home/mikef # cat /proc/version
Linux version 4.14.15-gentoo (root@djt) (gcc version 7.3.0 (Gentoo 7.3.0))
#1 SMP Tue Jan 30 16:22:47 GMT 2018

and now the spectre kernel checker says the following:

* Mitigation 2
  * Kernel compiled with retpoline option:  YES
  * Kernel compiled with a retpoline-aware compiler:  YES  (kernel reports
full retpoline compilation)
  * Retpoline enabled:  YES
> STATUS:  NOT VULNERABLE  (Mitigation: Full AMD retpoline)

New kernels are going to appear soon with fancier fixes for spectre
vulnerabilities if I understand it correctly.

I can now install them right away; and if I want I can downgrade gentoo
testing to gentoo stable and do the very same thing.

Cheers

MF



​


>
>
>
>
> ​
>
>
>
>
>
>
>>
>> ^
>>
>> Elimar
>> --
>>   You cannot propel yourself forward by
>>   patting yourself on the back.
>>
>>
>

Re: Kernel for Spectre and Meltdown

[Michael Fothergill]

On 29 January 2018 at 18:02, Michael Lange  wrote:

> On Mon, 29 Jan 2018 10:47:57 -0500
> rhkra...@gmail.com wrote:
>
> > Again, checking / confirming my understanding, if you download a kernel
> > image (which is normal for me), there is no need for me to have any
> > version of GCC as the image is pre-compiled.
>
> Sure.
>
> >
> > On the other hand, if I download kernel source, I would need GCC, and a
> > version that is sufficient for the code.
>
> That is point here, at least as far as I understood for that new "spectre
> fix" one needs a compiler that is "retpoline-aware" (as the
> "checker"-script calls it, whatever that means) and currently this is only
> true for gcc >= 7.3. So if you compile the kernel on Stretch with gcc-6
> this "retpoline" fix will not work.
>

​For me, the realisation of this felt as if a person had drunk too much
alcohol the night before,
and woke the next morning with a hangover.

After groping around in the medicine cabinet and finding the alka seltzer
one would realise that they
needed to take two tablets not just one to recover and face the reality of
the moment.

One could perhaps argue that the fact that one could use a live
distribution to run sid
and produce a kernel that could be ported to stretch plus the fact that some
kernels that address only the meltdown problem are knocking around in
stretch
etc might make one feel that perhaps one alka seltzer tablet might suffice
instead of two here.

Perhaps otherwise.

I am not really so sure what the correct dosage ought to be now.

Cheers

MF



>
> Regards
>
> Michael
>
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> Earth -- mother of the most beautiful women in the universe.
> -- Apollo, "Who Mourns for Adonais?" stardate 3468.1
>
>

Re: Kernel for Spectre and Meltdown

[Michael Fothergill]

On 30 January 2018 at 21:45, Michael Lange  wrote:

> On Tue, 30 Jan 2018 19:14:36 +
> Michael Fothergill  wrote:
>
> >
> > I am not really so sure what the correct dosage ought to be now.
>
> Maybe just stick with the booze... ;-)
>
> scnr
>
> Michael
>

​It's OK.  As it turns out, I don't drink but it is still funny..

Cheers

MF​


>
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> Fascinating is a word I use for the unexpected.
> -- Spock, "The Squire of Gothos", stardate 2124.5
>
>

Re: Kernel for Spectre and Meltdown

[Michael Fothergill]

On 30 January 2018 at 16:36, Michael Fothergill <
michael.fotherg...@gmail.com> wrote:

>
>
> On 30 January 2018 at 16:02, Michael Fothergill <
> michael.fotherg...@gmail.com> wrote:
>
>>
>>
>> On 30 January 2018 at 15:23, Elimar Riesebieter 
>> wrote:
>>
>>> * rhkra...@gmail.com  [2018-01-29 10:47 -0500]:
>>>
>>> [...]
>>> > On the other hand, if I download kernel source, I would need GCC, and a
>>> > version that is sufficient for the code.
>>>
>>> One can check the compiler version the running kernel is built with
>>> by:
>>>
>>> $ cat /proc/version
>>> Linux version 4.14.15-toy-lxtec-amd64 (riesebie@toy) (gcc version 7.3.0
>>> (Debian 7.3.0-1)) #1 SMP Tue Jan 30 14:20:49 CET 2018
>>>
>>
>> ​That is a very useful command.
>>
>> I ran it myself.
>>
>> djt /home/mikef/spectre-meltdown-checker # cat /proc/version
>> Linux version 4.14.14-gentoo (root@djt) (gcc version 7.2.0 (Gentoo
>> 7.2.0-r1)) #1 SMP Tue Jan 23 13:06:23 GMT 2018
>>
>> Here is a bit of the output from the spectre patch checker:
>>
>>
>> ​* Mitigation 2
>>   * Kernel compiled with retpoline option:  YES
>>   * Kernel compiled with a retpoline-aware compiler:  NO  (kernel reports
>> minimal retpoline compilation)
>>   * Retpoline enabled:  YES
>> > STATUS:  VULNERABLE  (Vulnerable: Minimal AMD ASM retpoline)
>>
>> ​As can be seen here, the compiler I used to create this kernel was not
>> recent enough to make retpoline work.
>>
>> Since I now have gcc 7.3 installed I will do kernel upgrade in a little
>> while and see if I can change the NO in
>>
>>   "* Kernel compiled with a retpoline-aware compiler:  NO  (kernel
>> reports minimal retpoline compilation)"
>>
>> to YES.
>>
>> I think it will work.
>>
>> Cheers MF
>>
>
> ​I just ran the kernel rebuild:
>
> djt /home/mikef # cat /proc/version
> Linux version 4.14.15-gentoo (root@djt) (gcc version 7.3.0 (Gentoo
> 7.3.0)) #1 SMP Tue Jan 30 16:22:47 GMT 2018
>
> and now the spectre kernel checker says the following:
>
> * Mitigation 2
>   * Kernel compiled with retpoline option:  YES
>   * Kernel compiled with a retpoline-aware compiler:  YES  (kernel reports
> full retpoline compilation)
>   * Retpoline enabled:  YES
> > STATUS:  NOT VULNERABLE  (Mitigation: Full AMD retpoline)
>
> New kernels are going to appear soon with fancier fixes for spectre
> vulnerabilities if I understand it correctly.
>
> I can now install them right away; and if I want I can downgrade gentoo
> testing to gentoo stable and do the very same thing.
>
> Cheers
>
> MF
>

​It has occured to me that two distributions of linux could be useful for
the spectre kernel patches right now.

One is sabayon and the other is calculate linux.

Both are gentoo based distributions.  For a new linux user, I think they
could have some advantages over e.g. gentoo itself.

Both come with installers so you will avoid the funny learning curve
involved in gentoo installs.

Sabayon has its own binary package installer called equo (its answer to apt
in debian). AFAICT, you
can avoid installing kernels with emerge (compiling them) if you want; you
have a choice.

I think, but I am not 100% sure that you can take the ebuild file for
kernel 4.15 from the gentoo kernel source site and install it directly in
sabayon.
Calculate linux is similar but does not have the equo package installer.

I notice that it seems Fedora have made kernels with the spectre patch
available. Whether they run in the equivalent of the stable version of the
distribution I am not sure.

Cheers

MF











​



>
>
>
> ​
>
>
>>
>>
>>
>>
>> ​
>>
>>
>>
>>
>>
>>
>>>
>>> ^
>>>
>>> Elimar
>>> --
>>>   You cannot propel yourself forward by
>>>   patting yourself on the back.
>>>
>>>
>>
>

Re: Kernel for Spectre and Meltdown

[Michael Fothergill]

On 30 January 2018 at 13:22, Greg Wooledge  wrote:

> On Tue, Jan 30, 2018 at 12:13:47PM +0100, Michael Lange wrote:
> > Michael Fothergill  wrote:
> > > The response from Greg was the following:
> > >
> > > On Thu, Jan 25, 2018 at 12:36:46PM +, Michael Fothergill wrote:
> > > > ​If I become sid and install the kernel correctly, could I go back to
> > > being
> > > > just buster (sounds like an energy drink) and carry on using the new
> > > kernel?
> > >
> > > No.
> > >
> > > ***
> > >
> > > At that point I really did seem that:
> > >
> > > 1. I had no choice but to become sid/unstable here.
> >
> > I can only guess of course, I think probably they figured you would
> > upgrade your system to Sid, then compile a kernel and then *downgrade*
> > the system again to buster. The answer to that would clearly be "no".
> > But running a kernel compiled on a *different* Sid system on buster or
> > stretch is an entirely different thing of course.
>
> Yes, that's correct.  If you actually "become sid" (upgrade your whole
> system to sid), there is no going back.
>

What about if you became sid, made the spectre kernel and backed it up on a
usb drive
and then you backed up the work files and wiped the entire installation and
then
reinstalled stretch.

Could you then install the kernel on the usb drive or is that not possible
and, like full gender reassignment surgery
there really is no going back as it were...?

Cheers

MF​



>
> But you can set up a *separate* system (either an entirely new box,
> or a chroot into which you debootstrap sid, or a virtual machine, or a
> container, or whatever other fancy thing the kids are using these days),
> build a kernel .deb package there, *copy* that package to your buster
> system, and install it.
>
> Or you can do what most of us are doing: wait for the Debian security
> team (and, really, for the entire *world*) to figure out how best to
> approach, mitigate, and/or solve the issues.
>
> Meanwhile, I would recommend not letting random people get shell access
> to your critical systems.  Near as I can tell, exploiting a Spectre-type
> CPU vulnerability requires the ability to install and execute a program
> of the attacker's creation on the target system.  If you don't have
> users logging in and running commands, then you probably don't have to
> worry so much about this.  Unless I'm completely missing something.
>
> (If you have users issuing commands on your system through some other
> vector, like a PHP web-app exploit, then that's a bigger issue you
> should address directly.)
>
>

Re: Kernel for Spectre and Meltdown

[Michael Fothergill]

On 31 January 2018 at 18:31, Michael Lange  wrote:

> On Wed, 31 Jan 2018 17:54:36 +
> Michael Fothergill  wrote:
>
> >
> > What about if you became sid, made the spectre kernel and backed it up
> > on a usb drive
> > and then you backed up the work files and wiped the entire installation
> > and then
> > reinstalled stretch.
> >
> > Could you then install the kernel on the usb drive or is that not
> > possible and, like full gender reassignment surgery
> > there really is no going back as it were...?
>
> Maybe it would be a little less of "DIY-lobotomy" (or "gender
> reassignment", whichever you prefer :) if you install sid onto the usb
> drive instead and leave your default system intact.
> But then, if you are running buster and desperately want to
> build your own kernel *now*, you could probably just replace buster's
> gcc-7.2 with sid's 7.3 to keep you going.
>

​As it turns out I have installed debian on a usb before and booted it up
successfully.
It did occur to me that you could advise the new users to buy a raspberry
pi computer
and use that to run sid and then install the kernel on my from it.

Then I would have one machine which apparently cannot be infected with
meltdown and spectre
with both sid and the spectre enabled kernel on it (raspberry pi) due its
architecture
​and my PC running buster with the same kernel ported to it but I don't
really need it because
I already have it in my Gentoo installation:

ie Dumb and Dumber Heh Heh!

Cheers

MF





​

​


>
> Regards
>
> Michael
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> "Logic and practical information do not seem to apply here."
> "You admit that?"
> "To deny the facts would be illogical, Doctor"
> -- Spock and McCoy, "A Piece of the Action", stardate
>unknown
>
>

Re: Kernel for Spectre and Meltdown

[Michael Fothergill]

On 31 January 2018 at 22:46, Richard Hector  wrote:

> On 01/02/18 11:20, Michael Fothergill wrote:
> > As it turns out I have installed debian on a usb before and booted it up
> > successfully.
> > It did occur to me that you could advise the new users to buy a
> > raspberry pi computer
> > and use that to run sid and then install the kernel on my from it.
> >
> > Then I would have one machine which apparently cannot be infected with
> > meltdown and spectre
> > with both sid and the spectre enabled kernel on it (raspberry pi) due
> > its architecture
>
> A complicated and expensive solution. The Pi being a different
> architecture means you'd need to take extra steps to cross-compile the
> kernel. A virtual machine, chroot, container or whatever is much cheaper
> and simpler.
>

​I agree.  It's much a better idea.  But we were actively trying to be dumb
in these exchanges for a bit of fun..

Cheers

​MF​
​


>
> Richard
>
>
>

Re: Kernel for Spectre and Meltdown

[Michael Fothergill]

On 31 January 2018 at 23:13, Richard Hector  wrote:

> On 01/02/18 11:51, Michael Fothergill wrote:
> >
> >
> > On 31 January 2018 at 22:46, Richard Hector  > <mailto:rich...@walnut.gen.nz>> wrote:
> >
> > On 01/02/18 11:20, Michael Fothergill wrote:
> > > As it turns out I have installed debian on a usb before and booted
> it up
> > > successfully.
> > > It did occur to me that you could advise the new users to buy a
> > > raspberry pi computer
> > > and use that to run sid and then install the kernel on my from it.
> > >
> > > Then I would have one machine which apparently cannot be infected
> with
> > > meltdown and spectre
> > > with both sid and the spectre enabled kernel on it (raspberry pi)
> due
> > > its architecture
> >
> > A complicated and expensive solution. The Pi being a different
> > architecture means you'd need to take extra steps to cross-compile
> the
> > kernel. A virtual machine, chroot, container or whatever is much
> cheaper
> > and simpler.
> >
> >
> > ​I agree.  It's much a better idea.  But we were actively trying to be
> > dumb in these exchanges for a bit of fun..
>
> Ah ... well in that case, why not cross-compile on a Windows box? :-)
>

​Now that is getting creative.​


​The ultimate would be if you could do it on a quantum computer..​

​MF​

>
> I guess firing up an AWS or Linode or something sounds much too sane (it
> might even be easier than setting up a local VM, depending where your
> capabilities lie).
> ​
>


> Richard
>
>

Re: Kernel for Spectre and Meltdown

[Michael Fothergill]

On 30 January 2018 at 13:22, Greg Wooledge  wrote:

> On Tue, Jan 30, 2018 at 12:13:47PM +0100, Michael Lange wrote:
> > Michael Fothergill  wrote:
> > > The response from Greg was the following:
> > >
> > > On Thu, Jan 25, 2018 at 12:36:46PM +, Michael Fothergill wrote:
> > > > ​If I become sid and install the kernel correctly, could I go back to
> > > being
> > > > just buster (sounds like an energy drink) and carry on using the new
> > > kernel?
> > >
> > > No.
> > >
> > > ***
> > >
> > > At that point I really did seem that:
> > >
> > > 1. I had no choice but to become sid/unstable here.
> >
> > I can only guess of course, I think probably they figured you would
> > upgrade your system to Sid, then compile a kernel and then *downgrade*
> > the system again to buster. The answer to that would clearly be "no".
> > But running a kernel compiled on a *different* Sid system on buster or
> > stretch is an entirely different thing of course.
>
> Yes, that's correct.  If you actually "become sid" (upgrade your whole
> system to sid), there is no going back.
>
> But you can set up a *separate* system (either an entirely new box,
> or a chroot into which you debootstrap sid, or a virtual machine, or a
> container, or whatever other fancy thing the kids are using these days),
> build a kernel .deb package there, *copy* that package to your buster
> system, and install it.
>
> Or you can do what most of us are doing: wait for the Debian security
> team (and, really, for the entire *world*) to figure out how best to
> approach, mitigate, and/or solve the issues.
>

​But surely it would be more efficient for anyone in the entire world who
is new to linux
to mitigate it most effectively at present by installing and running a
distro that does the following things:

1. On installation of the OS you either automatically get the latest kernel
with both spectre and meltdown patches included ab initio.

2.  If you don't get that kernel by default you can install it easily and
promptly without difficulty as a new user and run with it.

3.  You can do this running that OS as the stable version, not needing to
be testing or unstable at all as part of the kernel installation prcess.

4. The OS installation process would be simple (ie not gentoo); candidates
here could be Sabayon, calculate linux and possibly Fedora.

Thus for anyone in the entire world who is new to linux,the most efficient
route at present could well be
to install Fedora and be stable and spectre protected out of the box rather
than taking on the indefatigable odyssey of installing Debian
and waiting for Debian security team to find solutions at whatever pace is
possible given the way
the distro is currenty set up.

Cheers

MF




​


>
> Meanwhile, I would recommend not letting random people get shell access
> to your critical systems.  Near as I can tell, exploiting a Spectre-type
> CPU vulnerability requires the ability to install and execute a program
> of the attacker's creation on the target system.  If you don't have
> users logging in and running commands, then you probably don't have to
> worry so much about this.  Unless I'm completely missing something.
>
> (If you have users issuing commands on your system through some other
> vector, like a PHP web-app exploit, then that's a bigger issue you
> should address directly.)
>
>

Re: Kernel for Spectre and Meltdown

[Michael Fothergill]

On 2 February 2018 at 04:35, Andy Smith  wrote:

> Hello,
>
> On Thu, Feb 01, 2018 at 11:53:36AM +, Michael Fothergill wrote:
> > Thus for anyone in the entire world who is new to linux,the most
> > efficient route at present could well be to install Fedora and be
> > stable and spectre protected out of the box rather than taking on
> > the indefatigable odyssey of installing Debian and waiting for
> > Debian security team to find solutions at whatever pace is
> > possible given the way the distro is currenty set up.
>
> "The way the distro is [currently] set up" is that the upstream
> Linux kernel project will provide backports to long term supported
> kernel versions and these will get folded into Debian stable as a
> security update. What you call an "indefatigable odyssey" will for
> the average Debian user be an unremarkable kernel upgrade.


​I think it could be a remarkable or noticeable thing  ​to a new debian or
linux user who
was interested to apply the latest available solution for e.g. spectre
together
with meltdown promptly to relatively standard installation.

If that is possible now in e.g. Fedora it is not unreasonable to want it to
exist
in Debian from my point of view.

Perhaps the average debian user may not be that bothered about the problem,
but a new debian user really did take the trouble to email on the site here
and ask us about this very thing.

And so, as peculiar as it seem to some people, I am
trying to consider what would work practically for such individuals.

And there
> will hopefully be minimal breakage because a lot of people will have
> tested it first.
>

​If it took e.g. 2 years of testing it before it would be released I am
sure it would be fine in terms of stability etc.
But would that be efficient here?​


>
> You appear to have a level of paranoia that requires you to build
> the latest kernel release with the latest GCC, and that has
> motivated you to learn how to do that on Debian, but I feel sure
> that that is not where the average Debian user is coming from.
>

Paranoia was not the motivation on my part at all here.  I could see that
kernel installations
was easy in gentoo, and this prompted me to see how easy it would be in
Debian.​


>
> As you've seen, the method is there for you to do what you have
> decided you need to do. Or for the curious who want a learning
> experience.


​I think the method is not really fit for purpose at present.​



> But with Meltdown dealt with by KPTI (already in the
> stable release) and the obvious javascript issues worked around by
> the browsers, you have to weigh up the risk of pushing hasty fixes
> into a stable kernel (and GCC) release.
>

​For me that is too much "odyssey" for the maximal efficiency for new
users.​


>
> I don't think the sky has fallen just yet but if you do want to see
> the sky fall, push out a buggy Debian stable kernel package.


​I don't see why it would need to be that buggy really.​



> Debian
> already has a place to test the latest and greatest (and most
> broken) versions of packages and it is not the stable release that
> new users are directed at.
>

​Do you mean that new users on average want to install testing etc rather
than stable?​


>
> Cheers,
> Andy
>

​In general I think some psychotherapy is required to reduce the
indefatigability factor here ,
and odyssey minimisation would be a good idea.​
 ​

​Cheers

MF​



> --
> https://bitfolk.com/ -- No-nonsense VPS hosting
>
>

Re: Kernel for Spectre and Meltdown

[Michael Fothergill]

On 3 February 2018 at 15:37, Cindy-Sue Causey 
wrote:

> On 2/3/18, rhkra...@gmail.com  wrote:
> > On Saturday, February 03, 2018 02:47:43 AM Michael Fothergill wrote:
> >> On 2 February 2018 at 04:35, Andy Smith  wrote:
> >> > Debian
> >> > already has a place to test the latest and greatest (and most
> >> > broken) versions of packages and it is not the stable release that
> >> > new users are directed at.
> >>
> >> ​Do you mean that new users on average want to install testing etc
> rather
> >> than stable?​
> >
> > I shouldn't profess to speak for someone else, but I think he meant just
> the
> >
> > opposite.  (I guess, to be fair, it could be read either way, but the
> > context
> > or something makes me favor my interpretation.)
>
>
> I missed this the first go-round. My interpretation of Andy's
> observation is that something cognitive about how certain pages read
> *might* accidentally point new users toward.. unstable and/or testing?
>
> ​I am intrigued here.  I actually upgraded to sid myself to try to
install these new kernels.
Maybe there is some kind of subtle subliminal force drawing me to do this
here that I was not aware of.

Who knows.

This could turn out to be more interesting than the discussion about the
kernel installations themselves.

MF​




> Cindy :)
> --
> Cindy-Sue Causey
> Talking Rock, Pickens County, Georgia, USA
>
> * runs with duct tape *
>
>

Re: Kernel for Spectre and Meltdown

[Michael Fothergill]

On 3 February 2018 at 17:12, David Wright  wrote:

> On Sat 03 Feb 2018 at 07:47:43 (+), Michael Fothergill wrote:
> > On 2 February 2018 at 04:35, Andy Smith  wrote:
> >
> > > Hello,
> > >
> > > On Thu, Feb 01, 2018 at 11:53:36AM +, Michael Fothergill wrote:
> > > > Thus for anyone in the entire world who is new to linux,the most
> > > > efficient route at present could well be to install Fedora and be
> > > > stable and spectre protected out of the box rather than taking on
> > > > the indefatigable odyssey of installing Debian and waiting for
> > > > Debian security team to find solutions at whatever pace is
> > > > possible given the way the distro is currenty set up.
> > >
> > > "The way the distro is [currently] set up" is that the upstream
> > > Linux kernel project will provide backports to long term supported
> > > kernel versions and these will get folded into Debian stable as a
> > > security update. What you call an "indefatigable odyssey" will for
> > > the average Debian user be an unremarkable kernel upgrade.
> >
> >
> > ​I think it could be a remarkable or noticeable thing  ​to a new debian
> or
> > linux user who
> > was interested to apply the latest available solution for e.g. spectre
> > together
> > with meltdown promptly to relatively standard installation.
>
> That is an unrealistic expectation, which can be seen by comparison
> with other walks in life. Regular airline pilots have to train and
> graduate to become test pilots.
>
> > If that is possible now in e.g. Fedora it is not unreasonable to want it
> to
> > exist
> > in Debian from my point of view.
>
> Fedora should not be compared with Debian stable:
>
> "We recognize that there is also a place for long-term stability in the
> Linux ecosystem, and that there are a variety of community-oriented
> and business-oriented Linux distributions available to serve that
> need. However, the Fedora Project’s goal of advancing free software
> dictates that the Fedora Project itself pursue a strategy that
> preserves the forward momentum of our technical, collateral, and
> community-building progress. Fedora always aims to provide the future,
> first."
>
> > Perhaps the average debian user may not be that bothered about the
> problem,
> > but a new debian user really did take the trouble to email on the site
> here
> > and ask us about this very thing.
> >
> > And so, as peculiar as it seem to some people, I am
> > trying to consider what would work practically for such individuals.
>
> Last month, you posted around 75 contributions to this thread and its
> colleagues, so it's difficult to be sure of exactly who you mean
> without a reference, but I'm going to hazard a guess: the person
> technically at the top of this thread, Dextin Jerafmel.
>



>
> If that is the case, then the "very thing" they asked was how to
> recognise and install the latest version of the kernel in Debian
> stable (9.3) because they weren't yet familiar with the difference
> between kernel version numbers (including the ABI version) and
> Debian versions.
>
> ​The title of the post "​
Kernel for Spectre and Meltdown
​" was created by the OP
He also wrote: ​"But in Your site You've mentioned Kernel for Debian
Stretch is 4.9.65 and You updated it for Spectre and Meltdown bugs"

It does not seem unreasonable that he would be interested in installing
kernels that address this problem and others could be as well.

If you want to address the spectre vulnerability, which he has referred to
in his post, you need a recent kernel.



> > And there
> > > will hopefully be minimal breakage because a lot of people will have
> > > tested it first.
> > >
> >
> > ​If it took e.g. 2 years of testing it before it would be released I am
> > sure it would be fine in terms of stability etc.
> > But would that be efficient here?​
>
> So 2 years is your Aunt Sally.
>

​No, I am aware that the problems could be addressed more quickly than that
as was pointed out to me and I acknowledged in earlier posts.
I am trying to suggest one would want to move faster than the approximate
cycle time of new stable releases here.
​


>
> > > You appear to have a level of paranoia that requires you to build
> > > the latest kernel release with the latest GCC, and that has
> > > motivated you to learn how to do that on Debian, but I feel sure
> > > that that is not where the average Debian user is coming from.
> > >
> >
> &

Re: Kernel for Spectre and Meltdown

[Michael Fothergill]

On 3 February 2018 at 21:43, Michael Fothergill <
michael.fotherg...@gmail.com> wrote:

>
>
> On 3 February 2018 at 17:12, David Wright 
> wrote:
>
>> On Sat 03 Feb 2018 at 07:47:43 (+), Michael Fothergill wrote:
>> > On 2 February 2018 at 04:35, Andy Smith  wrote:
>> >
>> > > Hello,
>> > >
>> > > On Thu, Feb 01, 2018 at 11:53:36AM +, Michael Fothergill wrote:
>> > > > Thus for anyone in the entire world who is new to linux,the most
>> > > > efficient route at present could well be to install Fedora and be
>> > > > stable and spectre protected out of the box rather than taking on
>> > > > the indefatigable odyssey of installing Debian and waiting for
>> > > > Debian security team to find solutions at whatever pace is
>> > > > possible given the way the distro is currenty set up.
>> > >
>> > > "The way the distro is [currently] set up" is that the upstream
>> > > Linux kernel project will provide backports to long term supported
>> > > kernel versions and these will get folded into Debian stable as a
>> > > security update. What you call an "indefatigable odyssey" will for
>> > > the average Debian user be an unremarkable kernel upgrade.
>> >
>> >
>> > ​I think it could be a remarkable or noticeable thing  ​to a new debian
>> or
>> > linux user who
>> > was interested to apply the latest available solution for e.g. spectre
>> > together
>> > with meltdown promptly to relatively standard installation.
>>
>> That is an unrealistic expectation, which can be seen by comparison
>> with other walks in life. Regular airline pilots have to train and
>> graduate to become test pilots.
>>
>> > If that is possible now in e.g. Fedora it is not unreasonable to want
>> it to
>> > exist
>> > in Debian from my point of view.
>>
>> Fedora should not be compared with Debian stable:
>>
>> "We recognize that there is also a place for long-term stability in the
>> Linux ecosystem, and that there are a variety of community-oriented
>> and business-oriented Linux distributions available to serve that
>> need. However, the Fedora Project’s goal of advancing free software
>> dictates that the Fedora Project itself pursue a strategy that
>> preserves the forward momentum of our technical, collateral, and
>> community-building progress. Fedora always aims to provide the future,
>> first."
>>
>> > Perhaps the average debian user may not be that bothered about the
>> problem,
>> > but a new debian user really did take the trouble to email on the site
>> here
>> > and ask us about this very thing.
>> >
>> > And so, as peculiar as it seem to some people, I am
>> > trying to consider what would work practically for such individuals.
>>
>> Last month, you posted around 75 contributions to this thread and its
>> colleagues, so it's difficult to be sure of exactly who you mean
>> without a reference, but I'm going to hazard a guess: the person
>> technically at the top of this thread, Dextin Jerafmel.
>>
>
>
>
>>
>> If that is the case, then the "very thing" they asked was how to
>> recognise and install the latest version of the kernel in Debian
>> stable (9.3) because they weren't yet familiar with the difference
>> between kernel version numbers (including the ABI version) and
>> Debian versions.
>>
>> ​The title of the post "​
> Kernel for Spectre and Meltdown
> ​" was created by the OP
> He also wrote: ​"But in Your site You've mentioned Kernel for Debian
> Stretch is 4.9.65 and You updated it for Spectre and Meltdown bugs"
>
> It does not seem unreasonable that he would be interested in installing
> kernels that address this problem and others could be as well.
>
> If you want to address the spectre vulnerability, which he has referred to
> in his post, you need a recent kernel.
>
>
>
>> > And there
>> > > will hopefully be minimal breakage because a lot of people will have
>> > > tested it first.
>> > >
>> >
>> > ​If it took e.g. 2 years of testing it before it would be released I am
>> > sure it would be fine in terms of stability etc.
>> > But would that be efficient here?​
>>
>> So 2 years is your Aunt Sally.
>>
>
> ​No, I am aware that the problems could be addressed more quickly than
> that as was p