Skip to content

Conversation

gnosek
Copy link
Contributor

@gnosek gnosek commented Sep 20, 2023

What type of PR is this?

This is a hard question :) Mostly "iterating over the same thing over and over until everybody is happy"

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind design

/kind documentation

/kind failing-test

/kind feature

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area API-version

/area build

/area CI

/area driver-kmod

/area driver-bpf

/area driver-modern-bpf

/area libscap-engine-bpf

/area libscap-engine-gvisor

/area libscap-engine-kmod

/area libscap-engine-modern-bpf

/area libscap-engine-nodriver

/area libscap-engine-noop

/area libscap-engine-source-plugin

/area libscap-engine-savefile

/area libscap-engine-udig

/area libscap

/area libpman

/area libsinsp

/area tests

/area proposals

Does this PR require a change in the driver versions?

/version driver-API-version-major

/version driver-API-version-minor

/version driver-API-version-patch

/version driver-SCHEMA-version-major

/version driver-SCHEMA-version-minor

/version driver-SCHEMA-version-patch

What this PR does / why we need it:

We want to be able to run source plugins without mounting /proc from the host. Unfortunately, the generic platform code does some /proc accesses, so we need the mount even for source plugins (which do not by themselves require any sort of OS access).

This PR makes the generic platform fully generic (and at the same time, fully no-op). This means we can remove the machine_info code for non-Linux platforms (since they do not have any "real" platform they could use).

This means that if you do need machine info, you need to use some other platform rather than generic (presumably the linux one). This can be enabled by passing SCAP_MODE_LIVE as the mode in sinsp::open_plugin and sinsp::open_test_input

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

This is definitely not the first time around the block with this, so I'm waiting for the inevitable "revert this" PR ;)

Does this PR introduce a user-facing change?:

NONE

Signed-off-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
Copy link
Member

@Andreagit97 Andreagit97 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok IMO the proposed changes are ok! Thank you!

Just a minor note:

void sinsp::init()
{
	//
	// Retrieve machine information
	//
	m_machine_info = scap_get_machine_info(m_h);
	if(m_machine_info != NULL)
	{
		m_num_cpus = m_machine_info->num_cpus;
	}
	else
	{
		ASSERT(false);
		m_num_cpus = 0;
	}
       ...

When we will use plugins with the generic_platform, in sinsp m_machine_info and m_agent_info will be pointers to empty structs so we cannot trust them (the good news is that there is no risk of segfault since in the scap platform we have structs and not pointers :)).

So in this fragment of code m_num_cpus = m_machine_info->num_cpus; will be probably set to 0 in the plugin case, but that could be acceptable at least for now, WDYT?

@Andreagit97 Andreagit97 added this to the 0.13.1 milestone Sep 20, 2023
@gnosek
Copy link
Contributor Author

gnosek commented Sep 20, 2023

We shouldn't crash since the info structs don't contain any pointers. Whether the defaults are OK, Cthulhu knows (libs don't really use these directly AFAIK)

@Andreagit97
Copy link
Member

Andreagit97 commented Sep 20, 2023

We shouldn't crash since the info structs don't contain any pointers. Whether the defaults are OK, Cthulhu knows (libs don't really use these directly AFAIK)

In sinsp they are used in some parsers like the clone one

/* Get pid namespace start ts - convert monotonic time in ns to epoch ts */
child_tinfo->m_pidns_init_start_ts = m_inspector->m_machine_info->boot_ts_epoch;

but right now we don't care about it since we are in a source plugin scenario without the syscall source enabled 👍

Signed-off-by: Andrea Terzolo <andreaterzolo3@gmail.com>
Co-authored-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
Copy link
Member

@Andreagit97 Andreagit97 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/approve

@poiana
Copy link
Contributor

poiana commented Sep 21, 2023

LGTM label has been added.

Git tree hash: edb204738250c2088bcb778e2ee87f1e1ab86329

Copy link
Contributor

@FedeDP FedeDP left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/approve

@poiana
Copy link
Contributor

poiana commented Sep 21, 2023

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Andreagit97, FedeDP, gnosek

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:
  • OWNERS [Andreagit97,FedeDP,gnosek]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@poiana poiana merged commit e999e61 into falcosecurity:master Sep 21, 2023
@Andreagit97 Andreagit97 mentioned this pull request Sep 21, 2023
3 tasks
@incertum
Copy link
Contributor

Oh hey @gnosek

Special notes for your reviewer:
This is definitely not the first time around the block with this, so I'm waiting for the inevitable "revert this" PR ;)

... the day has come ;)

Instead of reverting, would the following be acceptable to get out of the regression for the host metrics falcosecurity/falco#2821 when you run Falco w/ plugin source only, but still on Linux.

  • Add a new sinsp_mode_t called SINSP_MODE_PLUGIN_HOST_METRICS (or similar) that complements SINSP_MODE_PLUGIN when running Falco w/ a plugin source only (no syscalls), but also with the Falco metrics framework enabled
  • When running in mode SINSP_MODE_PLUGIN_HOST_METRICS, allocate a new platform that could be called scap_linux_host_metrics_alloc_platform or similar. It would basically be a Linux light platform that would only alloc what is needed in order to have m_machine_info, m_agent_info and the iflist (for a new metrics field in the making) available to the metrics framework.
  • Other ideas?

@gnosek
Copy link
Contributor Author

gnosek commented Jul 22, 2024

Moved the discussion back to falcosecurity/falco#2821, working on a PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants