leaf-devel — This is a discussion list for development topics.

[leaf-devel] Missing device node for a USB based WiFi dongle

[Erich T. <eri...@th...>]

Hi Folks

I am trying to connect a WiFi dongle to my Pi Zero. It is a Mediatek el 
cheapo dongle which runs fine on my Pi3B+ on raspbian.

When I insert the dongle into a running system, it just crashes and 
reboots. Annoying as this may be I would ignore this for the moment. 
However the restarted system finds the driver for the hardware but does 
not set up the device node. Further investigation led to a missing 
firmware module for this little gizmo, e.g. mt7601u.bin.

In my despair I just copied it from the raspbian instance on the Pi3B+ 
and, being firmware for the dongle, it just loaded and now I got the 
device node.

How should we handle this kind of problems? Should we build a collection 
of firmware modules?

cheers

ET

Re: [leaf-devel] [leaf:bering-uclibc] New commit [022894] by Andrew Denisenko

[Erich T. <eri...@th...>]

Hi

Am 27.12.2020 um 09:27 schrieb LEAF Linux Embedded Appliance Framework 
Git repository:
> 
>     Branch: next-radius
> 
> libxml2: use staging dir in xml2-config prefix

Just for curiosity.
Why do we need such constructs in a makefile? Can't we specify --prefix 
correctly?

cheers

ET

Re: [leaf-devel] busybox modprobe does not respect /etc/modprobe.d/ entries

[Erich T. <eri...@th...>]

Am 14.09.2020 um 17:15 schrieb KP Kirchdoerfer via leaf-devel:
> Hi;
> 
> On So, 2020-09-13 at 22:03 +0200, Erich Titl wrote:
>> Am 13.09.2020 um 14:15 schrieb KP Kirchdoerfer via leaf-devel:
>>> Hi Erich;
>>>
>>> On Do, 2020-09-10 at 15:42 +0200, Erich Titl wrote:
>>>> Hi Folks
>>>>
>>>> I found a rather unpleasant behaviour in busybox's modprobe. It
>>>> appears
>>>> not to respect 'install' lines in files in /etc/modprobe.d.
>>>
>>> Indeed a limitation of busybox AFAIK.
>>>
>>>> This is annoying in the case of the module leds_gpio which may
>>>> depend
>>>> on
>>>> the underlying gpio driver, but which is not depending on it in
>>>> modules.dep (it cannot know what the dependency could be).
>>>>
>>>> Ideas?
>>>
>>> I usually add such "missing/unkown" modules in /etc/modules
>>
>> Unfortunately this does not do the job because leds_gpio is loaded
>> automagically _before_ the underlying driver gets loaded. I testet
>> this
>> with an ALIX board.
>>
>> The way to fix this is to rmmod leds_gpio and modprobe leds_gpio.
>> With a
>> _real_ modprobe this could be configured if this _real_ modprobe was
>> available it init.
> 
> Ok,
> 
> what module is missing?

None, but leds_gpoi is loaded too early by the autoloader.

> 
> According to kernel documentation GPIO_CS5535 & LEDS_GPIO needs to be
> loaded.
> Looking at my old ALIX box with 4.14 kernel I see
> 
> gpio_cs5535 16384 3 - Live 0xb885c000
> leds_gpio 16384 0 - Live 0xb889a000
> 
> detected by hwdetect without any changes elsewhere.
> 
> Though I've never tested to play with the LEDs on this box.
> What's the output of lsmod on your box?

They are both loaded but don't talkt to each other.

> 
> And what's going wrong?

LED's dont work and the /sys/class/leds are not initialized completely.

cheers

ET

-- 
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com

Re: [leaf-devel] busybox modprobe does not respect /etc/modprobe.d/ entries

[KP K. <ka...@us...>]

Hi;

On So, 2020-09-13 at 22:03 +0200, Erich Titl wrote:
> Am 13.09.2020 um 14:15 schrieb KP Kirchdoerfer via leaf-devel:
> > Hi Erich;
> > 
> > On Do, 2020-09-10 at 15:42 +0200, Erich Titl wrote:
> > > Hi Folks
> > > 
> > > I found a rather unpleasant behaviour in busybox's modprobe. It
> > > appears
> > > not to respect 'install' lines in files in /etc/modprobe.d.
> > 
> > Indeed a limitation of busybox AFAIK.
> > 
> > > This is annoying in the case of the module leds_gpio which may
> > > depend
> > > on
> > > the underlying gpio driver, but which is not depending on it in
> > > modules.dep (it cannot know what the dependency could be).
> > > 
> > > Ideas?
> > 
> > I usually add such "missing/unkown" modules in /etc/modules
> 
> Unfortunately this does not do the job because leds_gpio is loaded
> automagically _before_ the underlying driver gets loaded. I testet
> this
> with an ALIX board.
> 
> The way to fix this is to rmmod leds_gpio and modprobe leds_gpio.
> With a
> _real_ modprobe this could be configured if this _real_ modprobe was
> available it init.

Ok,

what module is missing?

According to kernel documentation GPIO_CS5535 & LEDS_GPIO needs to be
loaded.
Looking at my old ALIX box with 4.14 kernel I see

gpio_cs5535 16384 3 - Live 0xb885c000
leds_gpio 16384 0 - Live 0xb889a000

detected by hwdetect without any changes elsewhere.

Though I've never tested to play with the LEDs on this box.
What's the output of lsmod on your box?

And what's going wrong?

kp

> cheers
> 
> ET
> 

Re: [leaf-devel] busybox modprobe does not respect /etc/modprobe.d/ entries

[Erich T. <eri...@th...>]

Am 13.09.2020 um 14:15 schrieb KP Kirchdoerfer via leaf-devel:
> Hi Erich;
> 
> On Do, 2020-09-10 at 15:42 +0200, Erich Titl wrote:
>> Hi Folks
>>
>> I found a rather unpleasant behaviour in busybox's modprobe. It
>> appears
>> not to respect 'install' lines in files in /etc/modprobe.d.
> 
> Indeed a limitation of busybox AFAIK.
> 
>> This is annoying in the case of the module leds_gpio which may depend
>> on
>> the underlying gpio driver, but which is not depending on it in
>> modules.dep (it cannot know what the dependency could be).
>>
>> Ideas?
> 
> I usually add such "missing/unkown" modules in /etc/modules

Unfortunately this does not do the job because leds_gpio is loaded
automagically _before_ the underlying driver gets loaded. I testet this
with an ALIX board.

The way to fix this is to rmmod leds_gpio and modprobe leds_gpio. With a
_real_ modprobe this could be configured if this _real_ modprobe was
available it init.

cheers

ET

-- 
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com

Re: [leaf-devel] busybox modprobe does not respect /etc/modprobe.d/ entries

[KP K. <ka...@us...>]

Hi Erich;

On Do, 2020-09-10 at 15:42 +0200, Erich Titl wrote:
> Hi Folks
> 
> I found a rather unpleasant behaviour in busybox's modprobe. It
> appears
> not to respect 'install' lines in files in /etc/modprobe.d.

Indeed a limitation of busybox AFAIK.

> This is annoying in the case of the module leds_gpio which may depend
> on
> the underlying gpio driver, but which is not depending on it in
> modules.dep (it cannot know what the dependency could be).
> 
> Ideas?

I usually add such "missing/unkown" modules in /etc/modules

kp

> cheers
> 
> ET
> 

[leaf-devel] busybox modprobe does not respect /etc/modprobe.d/ entries

[Erich T. <eri...@th...>]

Hi Folks

I found a rather unpleasant behaviour in busybox's modprobe. It appears
not to respect 'install' lines in files in /etc/modprobe.d.

This is annoying in the case of the module leds_gpio which may depend on
the underlying gpio driver, but which is not depending on it in
modules.dep (it cannot know what the dependency could be).

Ideas?

cheers

ET

-- 
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com

[leaf-devel] LED support for alix in 7.0.0-rc1

[Erich T. <eri...@th...>]

Hi Folks

Booting my ALIX board with 7.0.0-rc1 yielded

[   44.412103] leds-gpio leds-gpio: Skipping unavailable LED gpio 6 (alix:1)
[   44.432501] leds-gpio leds-gpio: Skipping unavailable LED gpio 25
(alix:2)
[   44.453136] leds-gpio leds-gpio: Skipping unavailable LED gpio 27
(alix:3)

And indeed

SALT# ls /sys/class/leds
ath9k-phy0  ath9k-phy1

shows there is no driver interface for the leds on ALIX.  Back in 6.2.1
there used to be

gatekeeper# ls /sys/class/leds/
alix:1  alix:2  alix:3

There appears something to be missing in 7.0.0 we used to have before.

cheers

ET


-- 
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com

[leaf-devel] Extending Webconf (was Re: Webconf with admin password (extended))

[Erich T. <eri...@th...>]

Hi everybody

I would like to move this discussion to leaf-devel so if anyone is there
an interested it can be replied to and it gets archived.

I believe me made some progress in the last few weeks, making LEAF more
simple to install and configure, or at least laid the groundwork to do
so. I believe with the ability to access a LEAF router just the same as
any commercial product we can make it more attractive for a larger public.

I have to admit, the way the WEB gui is run right now is neither state
of the art nor will it ever be, as modern WEB interfaces are just
monsters. Right now it can be discussed if the foundation of the webconf
interface based on haserl is still adequate, the question is remaining:
What else could we use? Haserl is a very primitive http wrapper,
basically unpacking requests into environment variables and handing
everything just to the shell. There are more modern aproaches to this
but basically they are just shells in themselves or are communicating
with the shell through system calls, which have a number of issues.

Another issue with webconf is, that it has not been designed to
incorporate well with our package structure. It uses its own
initialisation to load .lwp files and is not integrated into the package
system at all. We could have built everything into the packages but this
was rejected a long time ago for reasons I could not understand then,
nor do I now.

I was thinking about giving leafinstall a web interface, allowing the
user to install LEAF on a new system without knowledge of the CLI. Every
commercial product does it this way, some better, some worse.Trying to
understand on how to implement this I found a number of difficulties,
not really related to the actual omplementation but on how to integrate
with the current package structure and philosophy.

Webconf is typically controlled by .lwp packages, basically a number of
.cgi files and possibly supporting library routines. So it should be
easy to just build a leafinstall.lwp and be done with it. Unfortunately
this is not the case. Such a WEB interface would be intrinsically
interwoven with the hdsupp package which provides the foundation to
access important system interfaces to hardware. In order to respect the
webconf structure this would call for a hdsupp.lwp which would
automagically be recognized by webconf and might be installed if
hdsupp.lrp is installed.

Thoughts?

ET

-- 
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com

Re: [leaf-devel] blkid in initrd

[KP K. <ka...@us...>]

Hi Erich;

On Mo, 2020-07-06 at 13:31 +0200, Erich Titl wrote:
> Bad Karma to respond to ones own message....
> 
> Am 06.07.2020 um 13:15 schrieb Erich Titl:
> > Hi
> > 
> > in root.linuxrc we are using blkid to identify devices. Now I could
> > not
> > find a blkid in buildtool.cfg for the initrd package. I was
> > wondering
> > where and when it disappeared.
> 
> I found that we have a blkid in busybox. Do we need another one in
> hdsupp?

Seems we don't:

#grep -R blkid repo/*/*
repo/e2fsprogs/buildtool.mk:    --disable-libblkid \
repo/hdsupp/buildtool.cfg:      fsck.ext3, fsck.msdos, fsck.vfat,
losetup, blkid, findfs
repo/hdsupp/buildtool.cfg:        Source          =
lib/libblkid.so.1.1.0
repo/hdsupp/buildtool.cfg:        Filename        =
lib/libblkid.so.1.1.0
repo/hdsupp/buildtool.cfg:        Filename        = lib/libblkid.so.1
repo/hdsupp/buildtool.cfg:        Target          =
lib/libblkid.so.1.1.0
repo/hdsupp/buildtool.cfg:        Source          = sbin/blkid
repo/hdsupp/buildtool.cfg:        Filename        = sbin/blkid
repo/initrd/root.linuxrc:# If blkid does not return true then lets just
drop the device.
repo/initrd/root.linuxrc:# Sometimes blkid returns true even if the
device cannot be identified
repo/initrd/root.linuxrc:               RESULT=$(blkid $dev)
repo/initrd/root.linuxrc:# we use the result from the blkid if it was
successful to extract
repo/nfs-utils/buildtool.mk:#   Disable uuid to avoid the need for
libblkid

regards kp

> cheers
> 
> ET
> 
> 
> _______________________________________________
> leaf-devel mailing list
> lea...@li...
> https://lists.sourceforge.net/lists/listinfo/leaf-devel

[leaf-devel] ncurses fails to compile in master/x86...

[Erich T. <eri...@th...>]

Hi Folks

ncurses fails to compile in master/x86...

/bin/sh ./run_tic.sh
** Building terminfo database, please wait...
Running tic to install
/home/mega/leaf/devel/master/build/x86_64-unknown-linux-uclibc/ncurses/usr/share/terminfo
...
....
....
"terminfo.tmp", line 4790, terminal 'xterm-16color': error writing
/home/mega/leaf/devel/master/build/x86_64-unknown-linux-uclibc/ncurses/usr/share/terminfo/x/xterm-16color
? tic could not build
/home/mega/leaf/devel/master/build/x86_64-unknown-linux-uclibc/ncurses/usr/share/terminfo

ideas?

ncurses compiles fine on unpacked (v 6.1) but not on master (v 6.2)

cheers

ET

[leaf-devel] configure: error: --with-pthreads specified for a system without pthread support

[Erich T. <eri...@th...>]

Hi Folks

This happens for nspr, any ideas?

cheers

ET

Re: [leaf-devel] blkid in initrd

[Erich T. <eri...@th...>]

Bad Karma to respond to ones own message....

Am 06.07.2020 um 13:15 schrieb Erich Titl:
> Hi
> 
> in root.linuxrc we are using blkid to identify devices. Now I could not
> find a blkid in buildtool.cfg for the initrd package. I was wondering
> where and when it disappeared.

I found that we have a blkid in busybox. Do we need another one in hdsupp?

cheers

ET

[leaf-devel] blkid in initrd

[Erich T. <eri...@th...>]

Hi

in root.linuxrc we are using blkid to identify devices. Now I could not
find a blkid in buildtool.cfg for the initrd package. I was wondering
where and when it disappeared.

cheers

ET

[leaf-devel] including toolchain binaries in git (sorry, last time bad sender address)

[Erich T. <eri...@th...>]

Hi everybody

I have a pretty slow environment at times. It takes hours just to
compile the toolchain, sometimes a day to just build the kernel and
several days to get a full compile.

Is it conceivable to keep the toolchain in git without necessarily
uploading it? I can imagine keeping it in a separate branch and even
have separate branches of this depending on kernel release and GCC version.

Thanks for ideas

ET

Re: [leaf-devel] [leaf-user] Bering 6.2.x and miniPCIe modules

[Erich T. <eri...@th...>]

Hi Otto

I had a look at the ALIX documentation and _believe_ that the miniPCIe
device is linked to the USB device.

I then had a look at my current config settings and compared the i486
and the geode USB settings.

I found the following

< # CONFIG_USB_PCI is not set
---
> CONFIG_USB_PCI=y

I can confirm that there have been USB config changes between 6.1.8 and
6.2.0. So it is possible that you are affected by these changes.

cheers

ET

Re: [leaf-devel] Possible bug in kernel compile

[KP K. <ka...@us...>]

Mv'ed to leaf-devel

On Sa, 2019-11-30 at 17:11 +0100, Erich Titl wrote:
> 
> Am 30.11.2019 um 16:04 schrieb KP Kirchdoerfer via leaf-devel:
> > Hi Erich;
> > 
> > On Do, 2019-11-28 at 13:02 +0100, Erich Titl wrote:
> > > Hi
> > > 
> > > The kernel compile for unpacked-next aka next aka possibly
> > > mmaster by
> > > now shows to be dependent on openssl headers. If these headers
> > > are
> > > not
> > > present on the compile system the compile fails. IMHO we should
> > > make
> > > kernel dependent on openssl and use the headers generated in the
> > > openssl
> > > build.
> > 
> > unpacked-next is the repository you can try and test whatever is
> > needed
> > to get the kernel compiled. It will not disturb any other yet.
> > 
> > Are you afraid of or has seen  any cons to build openssl before the
> > kernel?
> 
> No I just wanted to give you a heads-up as apparently this was
> something
> which has not been observed yet. I bet it happens in every branch, it
> is
> just masked if there is libssl-dev (in ubuntu) installed on the
> development system and I feel like this header should _not_ be used.
> I
> would call it a bug.

Ok; dare to commit to master as well?

kp



> ET
> 

Re: [leaf-devel] Possible bug in kernel compile

[KP K. <ka...@us...>]

Hi Erich;

On Do, 2019-11-28 at 13:02 +0100, Erich Titl wrote:
> Hi
> 
> The kernel compile for unpacked-next aka next aka possibly mmaster by
> now shows to be dependent on openssl headers. If these headers are
> not
> present on the compile system the compile fails. IMHO we should make
> kernel dependent on openssl and use the headers generated in the
> openssl
> build.

unpacked-next is the repository you can try and test whatever is needed
to get the kernel compiled. It will not disturb any other yet.

Are you afraid of or has seen  any cons to build openssl before the
kernel?

kp

> cheers
> 
> ET
> 
> _______________________________________________
> leaf-devel mailing list
> lea...@li...
> https://lists.sourceforge.net/lists/listinfo/leaf-devel

[leaf-devel] Possible bug in kernel compile

[Erich T. <eri...@th...>]

Hi

The kernel compile for unpacked-next aka next aka possibly mmaster by
now shows to be dependent on openssl headers. If these headers are not
present on the compile system the compile fails. IMHO we should make
kernel dependent on openssl and use the headers generated in the openssl
build.

cheers

ET

[leaf-devel] ISP in a box

[Mike N. <mh...@gm...>]

A new last mile ISP economic model.

Building an ISP in a box
https://www.youtube.com/watch?v=G4EKbgShyLw
36:23
TeamNANOG
Published on Jun 19, 2019

Re: [leaf-devel] Kernel config

[Erich T. <eri...@th...>]

Hi

Am 15.06.2019 um 18:55 schrieb KP Kirchdoerfer via leaf-devel:
> HI;
> 
> On Do, 2019-06-13 at 09:27 +0200, Erich Titl wrote:
>> Hi folks
>>
>> I did some work on a specific kernel config for old wrap systems and
>> got
>> frustrated by 2 issues.
>>
>> - despite my past advocacy for a difference based kernel config I
>> found
>> it was not very practical and does not save time
> 
> It depends on the task you need to accomplish. I have mixed results.
> 
> I have the suspicion that stuff from tah main config (i486) may leak
> into e.g. wrap weher it's unwanted - on the other hand adding a feature
> for all architectures is pretty easy the way we work today.
> 

I am not of the same opinion. The goal of splitting off a _main_ and a
diff file has _not_ lead to simplify the maintenance IMHO. We still have
to run oldconfig on all variants and then

- split the diff file apart
- just to reunite it again

And we do not even have a decent history because

- the filenames differ... see below.

> 
>> - including kernel release information in the names of the config
>> files
>> does IMHO help anything and is _not_ version tool friendly
> 
> I disagree; the release information is used from
> make/toolcahin/[architecture] and was introduced to allow a different
> kernel version for an architectures that won't build with the current
> kernel version.
> Though this isn't used very often, I've used it during on beta versions
> in the past - upgrading the kernel for ARCH=i386 whilst keeping the
> older kernel version for ARCH=arm.
And here I disagree :-) This is completely unnecessary, we are carrying
information in the Make process which is irrelevant to the process itself.

We can upgrade whatever we want without keeping a name in the file. Our
versioning tool does that for us and I bet it is a lot better at it then
the human being using it :-(

> 
>> So I would suggest to drop the diffing method and return to generic
>> config name, e.g.
>>
>> - drop the diffes and use enter the specific configurations into git
> 
> Both are there at the moment.
> 
>> - drop the kernel version in the config files and make them generic
>> (inside the various kernel source there is never a version mentioned
>> in
>> the filenames.
> 
> See make/toolchain

The toolchain is _not_ part of the kernel.

> 
> Just my 2 cents

Just like mine

I would suggest to keep your beloved old versioning but keeping a
parallel fully deployable copy of _real_ config files which dont't have
to be managed at every build invocation.

We can get rid of the basis File as there is no patch to be run anymore
in buildtool.mk. We can in the long run get rid of the python stuff
which is probably handled only by Andrew. I understand this is more
fancy but unfortunately unnecessary.

I can live with the idea of having to change the buildtool.mk for the
kernel and If you don't want to copy your Bering-{mumble}-variant.config
to a Bering-variant.config I will gladly to that for the released
versions. We probably don't need to update the kernel for every little
thing they do at kernel.org, but at the time we want to do a release.
Everything between leads just to dead source, but whatever. I wouls
olaso prefer to keep the kernel source as source in git and not as binaries.

But whatever...

You will soon see the benefit.

cheers

ET

---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com

Re: [leaf-devel] Kernel config

[KP K. <ka...@us...>]

HI;

On Do, 2019-06-13 at 09:27 +0200, Erich Titl wrote:
> Hi folks
> 
> I did some work on a specific kernel config for old wrap systems and
> got
> frustrated by 2 issues.
> 
> - despite my past advocacy for a difference based kernel config I
> found
> it was not very practical and does not save time

It depends on the task you need to accomplish. I have mixed results.

I have the suspicion that stuff from tah main config (i486) may leak
into e.g. wrap weher it's unwanted - on the other hand adding a feature
for all architectures is pretty easy the way we work today.


> - including kernel release information in the names of the config
> files
> does IMHO help anything and is _not_ version tool friendly

I disagree; the release information is used from
make/toolcahin/[architecture] and was introduced to allow a different
kernel version for an architectures that won't build with the current
kernel version.
Though this isn't used very often, I've used it during on beta versions
in the past - upgrading the kernel for ARCH=i386 whilst keeping the
older kernel version for ARCH=arm.

> So I would suggest to drop the diffing method and return to generic
> config name, e.g.
> 
> - drop the diffes and use enter the specific configurations into git

Both are there at the moment.

> - drop the kernel version in the config files and make them generic
> (inside the various kernel source there is never a version mentioned
> in
> the filenames.

See make/toolchain

Just my 2 cents
kp

> cheers
> 
> ET
> 
> 
> 
> _______________________________________________
> leaf-devel mailing list
> lea...@li...
> https://lists.sourceforge.net/lists/listinfo/leaf-devel

[leaf-devel] Kernel config

[Erich T. <eri...@th...>]

Hi folks

I did some work on a specific kernel config for old wrap systems and got
frustrated by 2 issues.

- despite my past advocacy for a difference based kernel config I found
it was not very practical and does not save time
- including kernel release information in the names of the config files
does IMHO help anything and is _not_ version tool friendly

So I would suggest to drop the diffing method and return to generic
config name, e.g.

- drop the diffes and use enter the specific configurations into git
- drop the kernel version in the config files and make them generic
(inside the various kernel source there is never a version mentioned in
the filenames.

cheers

ET

[leaf-devel] LOw entropy on slow devices

[Erich T. <eri...@th...>]

Hi Folks

I see very slow entropy gathering on slow devices such as a PCengines
WRAP using 6..2.0.

I recall having found a solution to speed this up some years ago using a
slightly different kernel configuation but these changes appear to be lost.

<KP> I recall a conversation about this but then </KP>¨

cheers
ET

Re: [leaf-devel] Spectre/meltdown fixes

[Andrew <ni...@se...>]

I think that Spectre v1 may have same performance impact. About meltdown 
- I'm not sure (AFAIR it's solved by strict dividing kernel-space memory 
address space and userspace memory address space, which slows down 
kernel->userspace communications). I just discovered it on AMD hardware 
w/o Meltdown/Spectre v1 vulnerabilities.

On 12.02.2019 18:41, KP Kirchdoerfer via leaf-devel wrote:
> On Fr, 2019-01-25 at 15:53 +0100, KP Kirchdoerfer via leaf-devel wrote:
>> Hi Andrew;
>>
>> On Do, 2019-01-24 at 17:41 +0200, Andrew wrote:
>>> Hi all.
>>>
>>> I upgraded one of BRASes to fresh LEAF 6.2 - and I saw that a lot
>>> of
>>> CPU
>>> time is wasted by spectre v2 protection:
>>>
>>>      PerfTop:   12411 irqs/sec  kernel:97.7%  exact:  0.0% [4000Hz
>>> cycles],  (all, 4 CPUs)
>>> -------------------------------------------------------------------
>>> -------------------------------------------------------------------
>>> ---------------------------------
>>>
>>>        6.63%  [kernel]          [k] __indirect_thunk_start
>>>        3.29%  [kernel]          [k] igb_alloc_rx_buffers
>>>        2.82%  [kernel]          [k] memcpy
>>>        2.69%  [kernel]          [k] ipt_do_table
>>>        2.03%  [kernel]          [k] fib_table_lookup
>>>        1.89%  [kernel]          [k] __netif_receive_skb_core
>>>        1.66%  [kernel]          [k] htb_dequeue
>>>        1.62%  [kernel]          [k] __skb_flow_dissect
>>>        1.56%  [kernel]          [k] igb_xmit_frame_ring
>>>        1.45%  bird              [.] 0x0000000000006a5c
>>>        1.41%  [kernel]          [k] __dev_queue_xmit
>>>        1.39%  [kernel]          [k] fib_table_flush
>>>        1.29%  [kernel]          [k] leaf_walk_rcu
>>>        1.25%  [kernel]          [k] irq_entries_start
>>>        1.22%  [kernel]          [k] tcp_packet
>>>
>>> Meltdown/spectre vulnerabilities are 1) exploitable mostly by
>>> local-running untrusted code, and 2) just can grant read access to
>>> some
>>> protected memory pages (for ex., FS cache which can contain
>>> passwords).
>>>
>>> I think that this isn't a cases which are suitable for LEAF box
>>> (which
>>> runs only trusted code, and which has no or almost no valuable
>>> plaintext
>>> data).
>> You may be right, but better safe than sorry.
>>
>>> I disabled it via kernel options, but maybe it'll be good to
>>> disable
>>> these protections in kernel at build time?
>>>
>>> Or as option, these protections may be disabled by default in
>>> kernel
>>> command line, with mention in documentation about this.
>>>
>>> Any thoughts?
>> Yes, I prefer The last one - "disabled by default on the kernel
>> command
>> line, but included in the kernel, and document how to enable
>> protection
>> by changing the kernel command line.
>>
>> Eventually the other way round - document how to disable the
>> protection
>> and gain some more CPU time with disabling in kernel command line, as
>> you did?
>>
>> Either of these would be fine with me.
>> What ever you choose, let me know what I should add to the wiki et
>> el.
> I've looked into again and we need to make a decision.
>
> First: it's the Spectre_2 fix wasting CPU cycles, it can be disavbled
> during boot with
> "spectre_v2=off"
> on the command line in syslinux.cfg.
>
> Spectre_v2 (CVE-2017-5715: variant 2 - branch target injection) is
> described as "Local attackers could use mis-predicted branches to
> speculatively execute code patterns that in turn could be made to leak
> otherwise non-readable content in the same address space,..."
>
> Andrew made the point that we do not have "local attackers" so let's
> turn it off by default and save CPU cycles/performance
>
> On the other hand "local attackers" might not be users, but malicious
> software delivered with an update of something we build but do not
> fully understand the implications - I agree this is a very theoritical
> example.
>
> Anyway a decision has to be made:
>
> Should the default be
> - be as secure as possible (probably without reason) and avoiding the
> perfomance penalty is up to the user by changing the kernel commandline
> in syslinux.cfg
>
> versus
>
> - disable Spectre V2 on the kernel commandline and it's up to the user
> to decide wether he want's to change back to maximum theoretical
> security even it has a performace issue.
>
> Opinions are welcome.
>
> kp
>
>
>
>
>
> _______________________________________________
> leaf-devel mailing list
> lea...@li...
> https://lists.sourceforge.net/lists/listinfo/leaf-devel