[lxc-users] Does cpu cgroup has been enabled in lxc/lxd

Fajar A. Nugraha list at fajar.net
Thu Nov 1 07:30:54 UTC 2018

On Thu, Nov 1, 2018 at 2:16 PM, kemi <kemi.wang at intel.com> wrote:

> On 2018/11/1 下午2:53, Fajar A. Nugraha wrote:
> > On Thu, Nov 1, 2018 at 1:38 PM, kemi <kemi.wang at intel.com> wrote:
> >
> >>>> g) and h) read files from /proc, not cgroup. You need lxcfs. You
> should
> >>>> already have that on ubuntu though.
> >>>>
> >>>>
> >>
> >> /proc/cpuinfo also matches the expected result.
> >> However, it seems that sysfs in container  still shares with host /sys
> >> file system.
> >> Right?
> >>
> >>
> >>
> > Correct. See https://linuxcontainers.org/lxcfs/introduction/
> >
> OK, then I have a question on scalability and security issues on running
> multiple containers.
> Background: Our customers hope to run hundreds or even thousands of
> containers in their production environment.
> Sharing sysfs of containers with host sysfs in lxc/lxd may have:
> a) security issue.
> If a malicious program in a container changes a sensitive file in /sys,
> e.g. reduce CPU frequency, does it really works? Does it affect other
> running containers?

Why don't you try it and see :)

Even privileged container should get something like this

# echo 1000000 > /sys/devices/system/cpu/cpufreq/policy1/scaling_min_freq
-su: /sys/devices/system/cpu/cpufreq/policy1/scaling_min_freq: Read-only
file system

There were some known security issues with /sys in the past (not cpufreq
though), but even back then it should be non issue for the default lxd
containers, which are unprivileged.

b) Scalability issue.
> E.g. During launching a ubuntu OS(not kernel) or Android OS in a
> container,it usually use udev/ueventd
> to manage their device. This device manager daemon will read or write
> uevent file in /sys, the kernel
> then broadcast a uevent to all the listeners(udev daemon) via netlink, if
> there are already hundreds
> of containers in the system, all of udev daemons need to deal with it, it
> would lead to a long boot
> latency which we have observed in docker.
LXD containers don't use udev.

> Anyway to fix that?

Try it, and if you find anything wrong, ask.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20181101/5a0dc215/attachment.html>

More information about the lxc-users mailing list