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

[kemi]

On 2018/11/1 下午3:30, Fajar A. Nugraha wrote:
> 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 :)
> 

this is just an example I used to help describe my question clearly.
I believe there are some other security issues in lxc/ldx due to shared sysfs.

> 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.
> 
> 

Yes. Using unprivileged container is a workaround, not very good though.

> 
> 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.
> 

I have no idea on how LXD container works now.
Maybe udev is disabled or some other mechanism may be used to manage device.

> 
> 
>> Anyway to fix that?
>>
> 
> 
> Try it, and if you find anything wrong, ask.
> 

The reason why I have not tried it is there is no available android image provided on existed
images server for LXD container. Do you know something about that?
So, I have to make a Android image first. Anyway I will try it next.
Thx for your answers again.