부트로더 (또는 하이퍼바이저) 프로그램 제작해주실 수 있는 분을 찾습니다
안녕하세요,
이곳에 이 글을 올려도 되는게 맞는지 모르지만 조심스럽게 올려봅니다..
아래와 같은 프로그램의 개발 의뢰를 받아주실 수 있는 분을 찾고 있습니다.
제작하려는 프로그램은 사물인터넷용 커널을 로딩하여 모니터링하는 하이퍼바이저입니다.
보드는 Conga-IA4를 사용하려 하는데, X86 i386 아키텍쳐입니다.
(ARM이 아니기 때문에, 일반 컴퓨터에서 사용하는 OS를 별도의 포팅 없이 바로 설치 가능합니다.)
<필요한 하이퍼바이저 (또는 부트로더) 프로그램의 요구사항>
- 사물인터넷용 소프트웨어 또는 IncludeOS, Zephyr와 같은 초소형 OS (단일 프로세스)를 디스크로부터 메모리에 로딩하여 부팅하는 소형 하이퍼바이저 제작
- 하이퍼바이저 (또는 부트로더)에서 운영체제 코드 로딩 시 운영체제 코드가 해킹으로 변조되지 않은 정상 상태인지 정상값과 비교/검사 (TPM 칩을 사용하여 검사)
- TPM 보안칩과 통신하여 TPM 칩에게 운영체제 코드의 sealing, unsealing, 또는 서명을 요청하는 드라이버 코드 제작 및 사용
- 운영체제 커널 (또는 사물인터넷 소프트웨어)이 동작하다가, 미리 지정된 특정한 인터럽트 신호 발생시, 최초의 부트로더 (또는 하이퍼바이저 모드)로 컨텍스트를 전환하여 지정된 인터럽트 루틴을 수행 (해당 루틴은 인터럽트가 발생된 코드의 위치 파악, 외부의 서버와 원격 통신 등입니다)
- 운영체제 코드를 로딩하여 부팅 후 정해진 일정 시간이 지나면 시스템을 처음부터 강제 재부팅
혹시 개발 의뢰를 맡아주실 수 있으시거나, 또는 그런 분을 알고 계시다면 realmemory2002@gmail.com으로 연락주시면 정말 감사드리겠습니다.
쉽게 가는 방법
요즘 하이퍼바이저 모드와 대등한 것이 Linux Container (LXC, Docker)입니다.
하이버바이저 대신 최신 커널에 LXC (Docker)올리고 그안에서 TPM 드라이버를 구동 시키면
1 쉽게 - 단시간
2 초소형 OS (2~5Mbyte)
만족 시킬 것 같습니다.
Linux Container 는 여기 참조: https://www.docker.com/
잘 모르지만 궁금해서 그런데요...
잘 모르지만 궁금해서 그런데요...
도커를 써도 게스트 OS 를 올리고...
게스트OS 에서 인터럽트 처리도 되는건가요?
안된다면 도커용 게스트 OS 를 래핑하는 작업까지 해야하지 않을까요?
그것이 간단할지 모르겠습니다. 게스트 OS 는 여러가지로 늘어날 수도 있을텐데...
Re:
> 게스트OS 에서 인터럽트 처리도 되는건가요?
예,
LXC (Linux Container, Docker)에서는 하이퍼바아저와 달리 커널이 하나입니다.
잘 이해가 되지 않습니다.
잘 이해가 되지 않습니다.
도커의 경우, 커널이 한개라고 말씀하셨는데...
그렇다면 게스트 OS 를 올린다는 것. 그리고 게스트 OS 에서 인터럽트 처리한다는 것이 이상하지 않습니까?
게스트 OS 를 올린다는 이야기는 새로운 커널을 돌린다는 이야기 아닙니까?
Re)
> 도커의 경우, 커널이 한개라고 말씀하셨는데...
기본적으로 Hypervisor(KVM)과 LXC의 차이를 먼저 이해하는 것이 도움이 됩니다.
아래에서 Docker/LXC 구조의 그림을 보시면 이해에 도움이 됩니다.
https://en.wikipedia.org/wiki/Docker_(software)
뭔가 문답이 되풀이 되는 느낌이 듭니다...
뭔가 문답이 되풀이 되는 느낌이 듭니다...
아무리 그림을 봐도.. 게스트 OS 커널이 없는데요...
어떻게 "IncludeOS, Zephyr와 같은 초소형 OS"를 돌릴수 있다는 것인지 모르겠습니다.
... 다른 분들은 다 이해하시는데 저만 이해 못하고 있는건가요?ㅠㅠ
Docker 안에서 TPM도 구동이 되는군요
근데 문제는 하이퍼바이저 자체도 초소형이어야 해서...
Re:)
Docker/LXC 쓰면 하이퍼바이저를 쓰지 않는 것이 되구요,
하이퍼바이저(하드웨어)를 쓰면 Docker/LXC 에 비해 프로그램 사이즈가 커지게 됩니다.
대신에 Docker를 돌리려면 리눅스 커널을 돌려야 하는 거지요?
근데 문제는 현재 삼고 있는 physical 하드웨어의 RAM 타겟 사양이 1~5MB 정도의 최저이거든요.
그런데 리눅스는 보통 300MB는 필요한 걸로 알고 있어서..
NetBSD 경우 5MB로 알고 있는데, 거기서 Docker가 돌아갈진 잘 모르겠어요.
On..
> 근데 문제는 현재 삼고 있는 physical 하드웨어의 RAM 타겟 사양이 1~5MB 정도의 최저이거든요.
일단 여기서 사이즈 정의를 두가지로 나누어 보겠습니다.
#1. Host 사이즈: 즉 하이퍼바이져 혹은 Container/Linux 사이즈:
3~4 MB 가능합니다. 단 설정에 따라 미묘하게 달라집니다.
#2. Guest OS (하이퍼바이져) 혹은 App (Container/Linux)사이즈:
1번 위에서 올라가는 것이죠:
A: 예를 들면 LXC/Container 경우에 BusyBox쓰면 2MB 입니다.
참조 :https://www.brianchristner.io/docker-image-base-os-size-comparison/
B: 하이퍼바이저를 쓰면 RTOS/Linux올려야 하겠죠. 즉 사이즈가 더 커지겠죠?
아시다시피, 하이퍼바이져는 기본적으로 하드웨어가 가상화의 몇몇 큰 블럭에 도움을 주고,
Container/LXC는 OS의 모든 구성요소를 작게 쪼개어 소프트웨어적으로 이바지합니다.
(제가 보기에 후자가 현상태까지 온 것은 다수의 오픈 소스 커널 개발자들이 근 10년간 이상 일해온 덕입니다..
몇몇은 자기들이 결국 가상화에 이바지하는 지도 모르면서... :-)
자세한 답장 감사합니다
전부터 NetBSD처럼 초소형 OS를 리눅스용으로 찾았었는데,
Alpine Linux에 있는지 몰랐는데, 올려주신 링크 보고 알게 되었어요.
감사합니다.
답변주신 글에서, Docker Image를 돌리는 Container Linux 사이즈가 3~4MB 가능하다고 하셨는데요:
(#1. Host 사이즈: 즉 하이퍼바이져 혹은 Container/Linux 사이즈:
3~4 MB 가능합니다. 단 설정에 따라 미묘하게 달라집니다.)
RAM 3~4MB 크기로 돌아가는 리눅스는 Alpine Linux밖에 없을 텐데,
그러면 Docker Image를 Alpine Linux로 돌리는 경우를 말씀하신 건가요?
그런데 Alpine Linux는 호환성 문제로 Docker가 잘 안돌아간다고 하는 말이 있는거 같습니다. (http://janhapke.com/blog/installing-docker-daemon-on-alpine-linux/)
Make Kldp Great Again
>RAM 3~4MB 크기로 돌아가는 리눅스는 Alpine Linux밖에 없을 텐데,
>그러면 Docker Image를 Alpine Linux로 돌리는 경우를 말씀하신 건가요?
사실 꼭 그렇지 않습니다.
가령 BusyBox 올리고 (2M) 본인이 필요한 라이브리러를 하나씩 하나씩 올리면서 총 사이지를
결정할 수 있습니다. 물론 이 경우에 시간/노력이 적지 않게 들어갑니다. (이런 기법은 여기 https://buildroot.org/)
Alpine Linux 사용하는 것은 있는 것을 그냥 가져다 쓰겠다는 것인데, Redundancy가 있겠죠.
Trade-off 입니다.
> Alpine Linux는 호환성 문제로 Docker가 잘 안돌아간다고 하는 말이 있는거 같습니다
사이즈 제한을 보니 제품을 생각중인 것 같습니다.
알다시피, Product을 만들 때는 오픈소스를 그냥 갖다가 맞추면 깔끔하게 폼 나오는 것이 거의 없습니다.
제가 보기게 Customisation 의 일부분입니다..
잘 알겠습니다
좋은 정보 주셔서 감사합니다.
type-1 (bare metal)
type-1 (bare metal) hypervisor - 자체 커널을 가지고 있습니다.
type-1 hypervisor 의 예로 종종 XEN 이 언급되는데, 사실은 미묘합니다.
XEN 은 dom0 guest OS 의 커널과 다른 guest OS 커널들 사이의 중계를 해주므로, 엄밀한 의미에선 type-1 hypervisor 가 아닙니다.
다른 open source 중에선 xvisor 같은 놈이 type-1 hypervisor 인데,
본질적으로 장치 드라이버를 hypervisor 커널 내에 구현해야만 guest OS 의 커널에서 사용할 수 있기 때문에 많은 노력이 필요합니다. (XEN 이 dom0 gusest OS 커널을 요구하는 것은 이것때문입니다.)
type-2 (hosted) hypervisor - 자체 커널이 없습니다.
type-2 hypervisor 의 예로는 linux KVM 이 있습니다. host OS 인 linux 커널의 kvm 이라는 드라이버가 hypervisor 역할을 합니다.
큰 돈 들이지 않고 일찍 성과가 나오는 방법을 찾고 계신거라면,
염두에 두고 계신 H/W platform 인 conga-ia4(x86) 보드의 BIOS(UEFI) 를 드냥 두시고,
XEN 을 이용하되 dom0 guest OS 로 Alpine linux 를 고려해보세요.
(램은 조금만 더 늘리시고요. 네트웍 스택 및 기타등등 드라이버가 포함된 리눅스 커널의 코드 용량이 꽤 큽니다.)
XEN 이 UEFI 로 잘 동작할런지는 모르겠지만,
conga-ia4 에 사용되는 N3000 계열, E8000 계열 CPU/SoC 의 FSP 를 Intel 사이트에서 제공하고 있고,
FSP 패키지에는 open source 인 legacy BIOS 계열의 Coreboot 에 포함시켜 빌드하는 문서가 포함되어 있으니,
여차하면 UEFI 를 버리고 legacy BIOS 로 갈아타는게 불가능하진 않다고 생각됩니다. 물론 말처럼 쉬울리는 결코 없지만.
LXC 는 hypervisor 도 아니고, virtual machine 도 아니고, emulator 도 아니고... (커널 부분을 제외한) virtual OS 라고 보시면 됩니다.
장점들이 없는 것은 아니지만 본문에 적으신 요구사항과는 여러모로 맞지 않습니다.
덧.
수량을 어느 정도로 잡으시는지 잘은 모르겠지만,
DDR(1/2/3) 1M 램을 구해서 다는 비용이 그리 저렴하지는 않을 것이라 생각됩니다. 오히려 고용량 모듈보다 비싸지나 않으면 다행이지 싶습니다.
XEN이 제일 합리적일거 같긴 합니다
여러모로 제일 이상적인 모델인거 같습니다.
다만 XEN이 Conga-IA4 또는 Minnowboard에 포팅이 가능할지 모르겠습니다.
위의 두 보드에 대한 포팅 성공 사례는 나와있지 않은 거 같아서요..
또한, Guest OS의 하이퍼바이저 call에 대해서
XEN 내부에 원격검증, 메모리 접근권한 에러 조사, 주기적 리부팅 등을 구현해야 하는데
이 구현하는 부분이 얼마나 어려울지 잘 모르겠네요.
어쩌다보니 Minnow board Turbot 에
어쩌다보니 Minnow board Turbot 에 XEN 을 올려봤네요.
BIOS 는 Intel 에서 배포하는 UEFI 그대로 사용했고요.
yocto 의 meta-virtualization 을 약간 개조해서 xen 과 dom0 linux 를 빌드했습니다.
+
하면서 알게됐는데 Baytrail (Atom E38xx) 는 vt-d 를 지원하지 않네요.
Intel 이 x86 전용 light weight
Intel 이 x86 전용 light weight hypervisor 를 개발해서 공개했는데, vt-d 가 없는 CPU 에서도 돌릴 수 있을지는 모르겠습니다.
https://projectacrn.org/