Re: LuaJIT Panic on IPFire

Re: LuaJIT Panic on IPFire

[Ghislain Hachey]

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

On 7/29/14, 18:00, development-request(a)lists.ipfire.org wrote:
>> I am trying to achieve something here I don't know if this is
>> >supported. I've built a custom addon for ntopng, a traffic monitoring
>> >tool which makes use of LuaJIT for its web UI scripting language
>> >(which is great for embedded devices). When starting the service on my
>> >home IPFire I quickly get the following error message.
>> >
>> >PANIC: unprotected error in call to Lua API (runtime code generation
>> >failed, restricted kernel?)
>> >
>> >Which leads me to think that a JIT is not supported in the kernel
>> >configuration of IPFire, or am I way off? This is a tool I'd really
>> >like to get working on my IPFire, any ideas?
> Check the kernel log. If PaX mprotect has stopped the execution it will
> be logged
> and in most cases the protection can disabled for single binaries with
> paxctl.
>
> Arne

Thanks Arne,

That seem to have fixed the problem.  I found the following in logs:

# grep -nir "pax" messages
311236:Jul 27 16:17:00 shockwave kernel: PAX: From 192.168.3.116: 
execution attempt in: <anonymous mapping>, 4eb62000-4ec2a000 4eb62000
311237:Jul 27 16:17:00 shockwave kernel: PAX: terminating task: 
/usr/local/bin/ntopng(ntopng):23772, uid/euid: 1001/1001, PC: 4eb69f89, 
SP: 4ac2af70
311238:Jul 27 16:17:00 shockwave kernel: PAX: bytes at PC: c7 05 bc a2 
c0 4e 01 00 00 00 8b 7a f8 8b 7f 08 81 7f 1c ff
311239:Jul 27 16:17:00 shockwave kernel: PAX: bytes at SP-4: 080f92b1 
4ec0a1c0 4ebcce00 4ebcce08 4ec0b328 4ebfcbf0 00000001 4ebfcbe0 4ec0a1f0 
00000000 081a0e8c 0815d816 080e7ccd 4ec0a1c0 00000000 00000000 00000000 
0819f2e4 0b076cd8 081a0e8c 080800b0

and I disabled mprotect with:

# paxctl -m /usr/local/bin/ntopng

Also, while I was familiarizing myself with grsecurity I noticed that other utilities such as pspax, execstack, scanelf and dumpelf are not available in IPFire. Is there a particular reason for this?

Regards,

  
--
GH

Re: IPFire Building Packages

[Michael Tremer]

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

On Sun, 2014-07-06 at 17:44 +0800, Ghislain Hachey wrote:
> On 7/6/14, 16:57, Michael Tremer wrote:
> > That's what we call bundled packages (very often libraries) and which
> > are extremely discouraged. The problem that comes with that is that when
> > a component gets updated to resolve a certain issue this problem is
> > still in the twenty other copies of the same software. Imagine that for
> > things like Heartbleed. It also consumes space, increases the build time
> > and so on.
> >
> > You should use the provided versions of those tools and libraries or
> > modify them if that is required. All other components that are missing
> > should be created as individual packages.
> 
> Yeah, I understand that. My only fear is that the software in question 
> is including those third party libs as deps because they are needed in a 
> very particular shape (specific versions, some source changes, etc.) to 
> make it all work properly as a whole. I will check with the developers 
> upstream regarding this and if not I will see if I can not modify the 
> build process to include those deps as individual packages in IPFire.

Bundled libs are a real worry and in the case some software requires a
certain version I would consider this software as seriously broken.

There is a reason why we have dynamic libraries and that those are
replaceable. We can easily fix bugs and security issues and those fixes
will get rolled out to the entire system. Therefore it is a must.

I wonder why I cannot find any documentation about this topic on our
wiki...

> Regarding IPFire version 3, If there are specific things I can do to 
> help, sure. I'll go through information in the links to get started.

Re: LuaJIT Panic on IPFire

[Ghislain Hachey]

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

Hi,

I am trying to achieve something here I don't know if this is supported. 
I've built a custom addon for ntopng, a traffic monitoring tool which 
makes use of LuaJIT for its web UI scripting language (which is great 
for embedded devices). When starting the service on my home IPFire I 
quickly get the following error message.

PANIC: unprotected error in call to Lua API (runtime code generation 
failed, restricted kernel?)

Which leads me to think that a JIT is not supported in the kernel 
configuration of IPFire, or am I way off? This is a tool I'd really like 
to get working on my IPFire, any ideas?

Regards,

--
GH

Re: LuaJIT Panic on IPFire

[Arne Fitzenreiter]

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

On 2014-07-29 10:13, Ghislain Hachey wrote:
> Hi,
> 
> I am trying to achieve something here I don't know if this is
> supported. I've built a custom addon for ntopng, a traffic monitoring
> tool which makes use of LuaJIT for its web UI scripting language
> (which is great for embedded devices). When starting the service on my
> home IPFire I quickly get the following error message.
> 
> PANIC: unprotected error in call to Lua API (runtime code generation
> failed, restricted kernel?)
> 
> Which leads me to think that a JIT is not supported in the kernel
> configuration of IPFire, or am I way off? This is a tool I'd really
> like to get working on my IPFire, any ideas?

Check the kernel log. If PaX mprotect has stopped the execution it will 
be logged
and in most cases the protection can disabled for single binaries with
paxctl.

Arne