Autores:  (1) Zane Weissman, Instituto Politécnico de Worcester Worcester, MA, EUA {zweissman@wpi.edu};  (2) Thomas Eisenbarth, Universidade de Lübeck Lübeck, SH, Alemanha {thomas.eisenbarth@uni-luebeck.de};  (3) Thore Tiemann, Universidade de Lübeck Lübeck, SH, Alemanha {t.tiemann@uni-luebeck.de};  (4) Berk Sunar, Instituto Politécnico de Worcester Worcester, MA, EUA {sunar@wpi.edu}.  Tabela de links   Resumo e Introdução   Fundo   Modelos de ameaças   Análise dos Sistemas de Contenção do Firecracker   Análise de Ataques e Defesas Microarquitetônicas em Microvms Firecracker   Conclusão, agradecimentos e referências  3. MODELOS DE AMEAÇA  Propomos dois modelos de ameaças aplicáveis a sistemas em nuvem sem servidor baseados em Firecracker:  (1) O modelo de usuário para usuário (Figura 3): um usuário mal-intencionado executa código arbitrário em área restrita dentro de uma VM do Firecracker e tenta vazar dados, injetar dados ou, de outra forma, obter informações ou controlar o aplicativo em área restrita de outro usuário. Neste modelo, consideramos  (a) o compartilhamento de hardware em fatias de tempo, onde as instâncias dos dois usuários são executadas alternadamente no núcleo da CPU, e  (b) colocalização física, onde o código dos dois usuários é executado simultaneamente em hardware compartilhado de uma forma ou de outra (por exemplo, dois núcleos na mesma CPU ou dois threads no mesmo núcleo se o SMT estiver habilitado).  (2) O modelo usuário-host (Figura 4): um usuário mal-intencionado tem como alvo algum componente do sistema host: o Firecracker VMM, KVM ou outra parte do kernel do sistema host. Para este cenário, consideramos apenas o compartilhamento de recursos de hardware em intervalos de tempo. Isso ocorre porque o host só executa o código se a VM do usuário convidado for encerrada, por exemplo, devido a uma falha de página que deve ser tratada pelo kernel do host ou pelo VMM.  Para ambos os modelos, assumimos que um usuário mal-intencionado é capaz de controlar o ambiente de execução de sua aplicação. Em nossos modelos, usuários mal-intencionados não possuem privilégios de kernel convidado. Portanto, ambos os modelos concedem ao invasor um pouco menos de privilégios do que o modelo assumido por [1], onde o kernel convidado é escolhido e configurado pelo VMM, mas considerado comprometido em tempo de execução. Em vez disso, os recursos do invasor em nossos modelos correspondem aos recursos concedidos aos usuários nas implantações do Firecracker no AWS Lambda e Fargate.  Este artigo está   sob licença CC BY-NC-ND 4.0 DEED. disponível no arxiv

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

AutoEncoder.tech

Research & publications on Auto Encoders, revolutionizing data compression and feature learning techniques.

Auto Encoder's blog

Este áudio é produzido no idioma original da história!

Muito longo; Para ler

Boost your HackerNoon story @ $159.99! 🚀

Segurança microarquitetônica do AWS Firecracker VMM: modelos de ameaças

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

Toque para ganhar: Telegram pode integrar os próximos 10 bilhões de usuários criptográficos antes de Solana

As camadas invisíveis: por que as entrevistas com usuários são um ativo insubstituível

Navegando pelas águas: desenvolvendo aplicações RAG de nível de produção com data lakes

Aumente sua produtividade com estas 18 ferramentas para desenvolvedores 🚀🔥

Toque para ganhar: Telegram pode integrar os próximos 10 bilhões de usuários criptográficos antes de Solana

As camadas invisíveis: por que as entrevistas com usuários são um ativo insubstituível

Navegando pelas águas: desenvolvendo aplicações RAG de nível de produção com data lakes

Aumente sua produtividade com estas 18 ferramentas para desenvolvedores 🚀🔥

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps