Osquery: building osquery on the raspberry pi 2 (ARMv7) - ubuntu MATE

[marcopashkov]

Hi,

I was trying to get osquery running on my raspberry pi 2. It all seems to come down to the ARM processor architecture. As far as I can tell osquery only supports x86-64 and i386. Do you plan to support ARM processors at some point?

The error messages that I get are:

• g++: error: unrecognized argument in option ‘-march=x86-64’
• g++: error: unrecognized argument in option ‘-mtune=i386’
• CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:16 (project)

What dependencies require non-ARM processors and is there a way you know of to compile OSQuery for ARM?

Thank you!

[marpaia]

ARM support is a worthy cause, we've talked about it a bit but nobody has gotten around to it yet. You should try! If you're running ubuntu or something, the dependencies (make deps) should work, but might require some manual intervention.

As far as the errors your getting, you're going to have to mess with CMake a bit for that. Grep around and you should be able to find all the flags which don't work on ARM (not surprising that -march=x86-64 isn't a valid ARM flag :) ). The Right Thing To Do would be to add ARM detection to CMake and conditionally add different flags when ARM vs x86-64.

[theopolis]

Hi @marcopashkov, for "normal" CMake-based projects the compiler options are sucked in through the environment or some sort of external CMake config. We choose to define a bit more in CMake and part of that includes building slightly non-optimized binaries designed for deployment to the largest number of possible x86-based CPUs, essentially no ISA extension sets.

For embedded devices and "devices resembling embedded devices" using ARM CPUs we might want to optimize completely for the native architecture/extensions. This assumes the build machine is the EXACT platform as the deployment. Non homogeneous deployments might not make sense here (but I have no evidence corroborating this, haha.)

There are two locations 1 and 2 you'll need to update. Hopefully the build (CMake) and dependency install scripts can use a ARM=1 style define to determine how to build.

[theopolis]

Hey @marcopashkov, it's been a few weeks! Did you make any process with the build, is there anything you're stuck on we could help with?

[marcopashkov]

Hey @theopolis, no, just busy with work. I'll respond to this thread when I get to it and made it work.

[theopolis]

Awesome! No worries or rush!

[marpaia]

@marcopashkov, I'm going to close this issue for now, just because we're trying to keep the open issue list lean for managing tasks within the internal team. When you get around to working on this, comment on this issue, we'll see it and we'll re-open it. Looking forward to your contribution :)

[xavinux]

Hi all, I`m trying to build osquery on a Raspberry Pi 3. The Linux distro is Raspbian with Kernel 4.9.41-v7+ on armv7l GNU/Linux. This is a 32bit OS. Question is if I need a 64bit Kernel/Operating System to start working with osquery. Thanks for your attention.

[marpaia]

@xavinux I believe that you do, but I am not 100% certain and I haven't verified before writing this.

[theopolis]

Hi all, a fair warning, this is a extremely difficult task. If you don’t regularly port code or are not intimate with operating systems and compilers, please know you have a lot of homework and reading ahead.

The osquery community will not offer much help in tutoring folks through this process. You, the person porting, will have to be the subject matter expert.

[xavinux]

Hi,
"If you don’t regularly port code or are not intimate with operating systems and compilers, please know you have a lot of homework and reading ahead."

I don't have any problem with homework and reading.

"The osquery community will not offer much help in tutoring folks through this process. You, the person porting, will have to be the subject matter expert."

Well, I'm not an expert, and very disappointed to know that the community can't help someone who is trying to contribute to this interesting project with this task that, as you say, seems to be very difficult to be done by only one person.

Anyway, thank you very much for your time to answer and sorry for the inconvenience.

[theopolis]

@xavinux, I just want to be super clear about expectations. The reason we cannot help is not because we choose not to, it’s because we do not have the knowledge. We love to help, as I hope is clear by all things related to osquery. But I want to set everyone up for success and that includes setting clear expectations.

[xavinux]

@theopolis no problem.

Maybe intead of "_The osquery community will not offer much help in tutoring folks through this process._* perhaps I think would've been better something like "_Try, and if you're stuck on something maybe we can help!_"

If we don't try because of the difficult of the idea and see how far can we go, will never get this work. Of course I understand that maybe, the osquery development team, don't have time to spend to make osquery run on a RPI, and that is why I offer to start working on this idea, if it could be useful, although I'm not an expert...

[ThorodanBrom]

Hello

I understand that ARM support is not at all in the pipeline, but the Linuxbrew based build is killing any efforts to try and get osquery to work with a Raspberry Pi 2. In addition to the expected errors in CMake, we have to deal with esoteric errors building an entire GCC toolchain (as far as I have understood from reading the code) using the custom osquery-local bottles.

Apart from trying to use v1.8.2, would you suggest any other way of building the stable without using brew on Linux.

[fmanco]

Hi @ThorodanBrom unfortunately we don't have plans to support something other than our current toolchain. If you have any plans to work on this I suggest you open a Blueprint issue and we can discuss there. I'm going to close this now.