Eisen is the first automated escheatment management system for banks and fintechs.

Eisen

eisen

Urgent vs Important: How To Fix Your Priorities Thanks to a study called ' ', we finally have evidence behind a bad habit most of us are guilty of: prioritizing urgent tasks over important ones. The Mere Urgency Effect We're more likely to focus on time-sensitive tasks even if they're not as value-driving as other tasks. Are you confused by the two adjectives I just compared? 'Urgent' and 'important' mean the same thing – don't they? Not quite. If you spend your days putting out fires and never feeling fulfilled by the tasks you get done, you're likely prioritizing urgent tasks – aka, those with deadlines – over important tasks that deliver more value in the long run. Enter the Eisenhower Matrix, an easy-to-understand and highly effective way of organizing tasks so that you can focus on what really matters in life. Let's take a closer look. Urgent and Important Are Not the Same Urgent tasks have a funny way of feeling much more important than they actually are. Whether it's the deadline associated with them, the pressure from a colleague to get it done, or simply their sense of immediacy, urgent tasks can seem like they're the be-all and end-all. They take so much of our attention, in fact, that we forget about the important tasks – things that help us reach our long-term goals; things that have a higher payout than smaller urgent tasks. Are You Prioritizing Low-Value Tasks? I'm going to pose a scenario to you. See if you can relate: It's 8 am on Monday morning. This week, your goal is to upgrade the onboarding pipeline for new users. Making it smoother and more intuitive will bring a lot more clients on board and increase your company's profits substantially. You plan on spending the first two hours of each day working toward this goal. Upon opening your laptop, however, you're immediately bombarded with emails requesting small changes to existing web pages. You can clearly see that the updates will make a difference, but they won't move the needle on your onboarding project. But... they're urgent. And your colleagues clearly need them done ASAP. By the time you're finished implementing these small changes, your two hours are up, and you need to move on to your other daily responsibilities. You haven't had a chance to work on the onboarding project. Sound Familiar? What often happens in this situation is we're so driven by the need to meet deadlines (official or self-imposed) that we skip the process of assessing which task is more valuable. Believe it or not, someone in history who deeply understood this fallacy – and worked to resolve it in his own life – was the 34th US president, Dwight D. Eisenhower. He said: "Especially whenever our affairs seem to be in crisis, we are almost compelled to give our first attention to the urgent present rather than to the important future." Eisenhower believed that urgent tasks aren't always important and that important tasks aren't always urgent. And – thanks to Stephen Covey, author of The 7 Habits of Highly Effective People – we can now understand exactly what he meant. The Eisenhower Matrix Covey created the Eisenhower Matrix to help the everyday hero prioritize tasks and projects. I personally live by this approach because, like many of you, my life as an entrepreneur is filled to the brim with 'urgent' tasks. The Matrix is simple; it sorts your tasks into one of four squares, all of which correspond to a different plan of attack. Visualize it as a two-by-two grid with 'urgent' and 'not urgent' on the x-axis and 'important' and 'not important' on the y-axis. Here's a breakdown of each square. 1. Urgent and Important Here, the time-sensitive and the high-value tasks collide. These are the tasks that need to be handled immediately. They'll require your full attention and should be taken care of as soon as possible. For example, I'd consider these to be both urgent and important: An emergency meeting with a large client who is considering leaving your business. It's urgent because they're just moments away from walking out the door, and it's important because a successful negotiation could mean maintained profits in the long run. A website bug fix that is driving away customers. You are literally losing money with each passing minute – so of course, you must fix this issue as soon as possible. Offboarding a disgruntled client. While there isn't an immediate financial consequence, it's still important to handle this quickly before any further damage is done. You can't predict how this client will react to the termination of their contract or whether they will attempt to sabotage your business in some way. To accurately determine which tasks are 'urgent and important', this needs to be a very intentional planning process – or your brain will default to prioritizing all tasks based on urgency alone. 2. Urgent, But Not Important These are tasks that require your attention but do not have a significant impact on the bottom line. You can safely delegate these to other team members (and you should, as soon as possible). I'm referring to tasks like: Submitting projects to clients. You're abiding by a pre-determined deadline, but it's a low-skill task that does not require your personal attention. Get someone else to take care of submissions. Proofreading this week's company e-newsletter. Even if you're committed to sending these out on the same day every week, you don't personally need to take care of the proofreading. That's what editors are for. Answering customer inquiries that don't relate to urgent orders or complaints. These can be handled by your support team without any additional involvement from you. Delegation is one of the most powerful skills you can master. (I'll cover that in a later newsletter, don't worry!) 3. Not Urgent, but Important Here, things get interesting. These are the tasks that can easily be pushed to the bottom of your priorities list because they don't appear urgent – but they should never be ignored. These are the tasks that will have a long-term or preventative impact on your business: Developing new marketing strategies for acquiring customers in competitive markets. This requires research and brainstorming, and it will take some time. But it's important to stay ahead of the competition and acquire customers in a way that is both cost-effective and long-lasting. Conducting team training sessions. L&D may not seem urgent, but high morale is essential for any business – and you can't expect your team members to be well-versed in their roles without proper training sessions. Gathering feedback from customers. Feedback is the best way to ensure that your products and services are meeting their needs. And, it's important for understanding what you can do better in the future. So that you don't forget about these tasks or push them down your list for too long, they need to be scheduled. Set up a recurring task in your calendar to work on these 'not urgent, but important' tasks. 4. Not Urgent, and Not Important Finally, let's talk about the delete pile. (Trust me – you don't need to think twice about these.) If you've got tasks on your list that are unimportant and not at all timebound, they're quite simply a waste of your time. A few examples include: Going down the LinkedIn rabbit hole. You might disguise this as 'competitor research', but let's be honest – all it does is dampen your confidence and make you compare your progress to other comparable startups. Attending events that have no purpose. Networking is an excellent thing to do. If you're simply attending something for a good social media post, however, it's a waste of your time. Updating company job listings. Are you happy with your current team? Have new applicants been flowing in? If so, doing things like updating job descriptions is not progress; it's procrastination. Some of these tasks can be eliminated altogether, while others can be safely forgotten about until a later date. Build an Eisenhower Habit As the study I mentioned earlier confirmed, we humans are impulsive with our prioritization. We're going to default to the tasks that feel most urgent. That is, unless we intentionally build a habit of using the Eisenhower Matrix. Carve out a few minutes each morning to review your task list and categorize each one according to the matrix. You'll be surprised at how quickly you'll start to see a difference in the way you prioritize your tasks – and, as a result, get more done. Good luck!

How to Fix Your Priorities Using the Eisenhower Matrix

আইজেনহাওয়ার ম্যাট্রিক্স ব্যবহার করে আপনার অগ্রাধিকারগুলি কীভাবে ঠিক করবেন

So legen Sie Ihre Prioritäten mithilfe der Eisenhower-Matrix fest

Cómo fijar tus prioridades usando la matriz de Eisenhower

Comment fixer vos priorités à l'aide de la matrice Eisenhower

आइजनहावर मैट्रिक्स का उपयोग करके अपनी प्राथमिकताओं को कैसे ठीक करें

アイゼンハワー マトリックスを使用して優先順位を修正する方法

아이젠하워 매트릭스를 사용하여 우선순위를 수정하는 방법

Como corrigir suas prioridades usando a matriz de Eisenhower

Eisenhower Matrisini Kullanarak Önceliklerinizi Nasıl Düzeltebilirsiniz?

Cách khắc phục các ưu tiên của bạn bằng Ma trận Eisenhower

如何使用艾森豪威尔矩阵确定优先事项

HackerNoon Reporter: Please tell us briefly about your background. Hi, I’m Jason! I grew up between Boston and Nashville. I then spent 10 years in Washington DC, first attending The American University studying International Relations, then 7 years as a consultant for USAID, World Bank, and others. I started spending time in East Africa through that work in 2010 and moved to Kenya in 2013 to start MARAMOJA, the first taxi app anywhere in Africa at the time. We realized in the process of building that taxi app that we were solving the wrong problem. We realized the problem was actually about trust. Then we began to focus our attention there, building better models of digital trust. What's your startup called? And in a sentence or two, what does it do? Our startup is called UTU, which means “humanity” in Swahili. UTU is building the trust infrastructure of the internet to help businesses and consumers engage and transact in an easier, safer, and more trustworthy way. Our AI-based API products collect and analyze data to create trust signals and personalized recommendations that help consumers and businesses make the best decisions for their situation. And the UTU blockchain protocol rewards users for trustworthy actions and compensates them for sharing their data while protecting their privacy. UTU changes the economics of trust, ensures trust can’t be bought or manipulated and leverages data to help people make better decisions. What is the origin story? As I mentioned earlier, UTU spawned from our work on MARAMOJA. In other more developed metropolitan areas, like New York and London, drivers and riders are interchangeable commodities. But in Kenya, and indeed in many parts of the world, trust is the key to how riders select drivers, and vice versa, and we realized this when building MARAMOJA. So we began working on new models of digital trust to support this. We realized that current online trust systems can’t always be trusted and are out of date. Anonymous ratings, reviews, and trust scores are often manipulated, static, and don’t reflect how we trust in the real world, which is based on relationships and connections. These issues lead to poor purchase decisions for consumers, and harmed reputations, and lost sales for online businesses. We also saw that artificial intelligence can be used to provide personalized recommendations based on users’ own networks and individualized models of trust. Even our earliest, simplest implementations of UTU’s concepts yielded +20% conversion rates and customer satisfaction, along with higher retention rates and lifetime value. People started reading about our approach to trust and coming to us from all over the world, telling us about the trust problems of their marketplaces, and asking to license our technology. This was the genesis of UTU. We later saw that blockchain can be leveraged to ensure that these ratings and reviews can’t be manipulated and that a token model could be layered in to reinforce our product value proposition with an economic incentive model that promotes digital trust. What do you love about your team, and why are you the ones to solve this problem? We’ve got both practical and theoretical knowledge and experience in trust. As mentioned, we first built the trust mechanism from a need that we encountered with MARAMOJA, so this is not just some theoretical game for us. Our CTO Bastian Blankenburg has also built and used trust models in his own research, and we’re collaborating with the University of Southampton in the UK in this respect. We have some of the strongest AI engineers and data scientists (many PhDs) on our engineering team. On the business side, we have serial entrepreneurs on our management team who have built, launched, and grown multiple companies. And we are extremely well connected on the African continent, which is a massive emerging market for crypto and faces many of the problems we are solving. If you weren’t building your startup, what would you be doing? I always struggle with this question. I’m building what I know to be my life’s work and there’s nothing else I should be doing other than this. When you get to wake up every day and try to move the world closer to a model of digital trust that actually works for people and improves our online experiences, there’s little cause or time to think about what else I might do. At the moment, how do you measure success? What are your core metrics? The metric we are optimizing for is the number of API calls for our products, which is a function of how many companies are using our APIs. So we are actively marketing and selling our Trust API to online marketplace companies, as well as our Creditworthiness API to financial services firms and decentralized finance (DeFi) lending platforms. What’s most exciting about your traction to date? The level of enthusiasm for what we’re building has been amazing. We’ve been able to garner about 15 pilot clients in a short amount of time. And what’s so interesting is that our solutions can be applied to so many different industries and use cases, and this range is reflected in our client base already. So we’re really excited to see how far-reaching we can be when we hit scale. What technologies are you currently most excited about, and most worried about? And why? I am most excited about the two technologies we’re working with today - blockchain and artificial intelligence. Within those, I’d say I’m excited by any technology that embraces our humanity, rather than seeking to replace it. Blockchain is able to transform the economics of products and give users and communities ownership in the platforms that they use. This is significantly changing how business is done today.  And the immutability of the data on the blockchain ensures that data, like ratings and reviews, can’t be manipulated. AI is another technology that is transformative. The ability to analyze and glean insights from massive amounts of data relatively quickly is amazing, and our personalized recommendations wouldn’t be possible without it. It’s ironic that one of the technologies that I am most worried about is also AI. We’ve heard all the stories about facial recognition and surveillance that are used to intrude on privacy, and this is all facilitated by AI. That’s why we are so adamant in ensuring that the data that we collect is done so with the permission of our users and that data is used in a privacy-preserving manner. What drew you to get published on HackerNoon? What do you like most about our platform? I’ve been reading Hacker Noon for many years now, and I admire how it went from being a developer-focused blog to a massive, wide-ranging tech publication. The content ranges from developer tutorials to life-improvement stories all focused on tech. It’s truly a unique reading experience, and we would be honored to be published on Hacker Noon. What advice would you give to the 21-year-old version of yourself? I’d probably tell myself to stop talking and listen. I’d also tell myself to stop trying to plan a career and start pursuing whichever things fascinate me at the time, and trust that all the dots will connect somehow. What is something surprising you've learned this year that your contemporaries would benefit from knowing? This year I’ve learned a tremendous amount about mental wellness and resilience. I’ve had a long and winding journey, with many challenges, professional and personal along the way. As an entrepreneur, our teams draw from our energy - staying mentally strong through the ups and downs of a startup is critical for both personal wellbeing and company success. I do this through a combination of meditation, yoga, and breathwork that help me stay centered and focused. Vote for UTU as . the startup of the year, Nairobi, Kenya

'UTU Changes the Economics of Trust', says Jason Eisen, CEO UTU

has an interesting past. She ‘came out’ as a long term CIA employee in January 2017 after Donald Trump delivered . Yael Eisenstat a poorly received speech in front of the C.I.A. Memorial Wall She didn’t intend to be sensationalist or release state secrets like some previous ex-secret service employees who revealed their identity, rather she had had enough of Trumps stream of insults to her country and hoped that her actions could make a difference. She has advised vice-presidents and major corporate companies and now works at New York University as an adjunct professor. Whilst at the eccentric and eclectic Tech Open Air in Berlin, I spoke with Yael to discuss technology, its impact on society, and we, or tech companies can and should do about it. Originally published at thenextweb.com on July 20, 2017. This post is part of our contributor series. The views expressed are the author’s own and not necessarily shared by TNW.

What effect is tech having on society? An interview with Yael Eisenstat

Your Guide For Overcoming Procrastination and Getting Down to Work

Is a Former President Entitled to Immunity? The U.S. Supreme Court Discusses

Ask These 10 Questions to Transform Your Leadership Approach

"AI can enhance data collection, analysis, prediction, and evaluation processes"

"এআই ডেটা সংগ্রহ, বিশ্লেষণ, ভবিষ্যদ্বাণী এবং মূল্যায়ন প্রক্রিয়াগুলিকে উন্নত করতে পারে"

„KI kann die Prozesse der Datenerfassung, -analyse, -vorhersage und -auswertung verbessern“

"La IA puede mejorar los procesos de recopilación, análisis, predicción y evaluación de datos"

"L'IA peut améliorer les processus de collecte, d'analyse, de prédiction et d'évaluation de données"

"एआई डेटा संग्रह, विश्लेषण, भविष्यवाणी और मूल्यांकन प्रक्रियाओं को बढ़ा सकता है"

「AIはデータの収集、分析、予測、評価のプロセスを強化できます」

"AI는 데이터 수집, 분석, 예측, 평가 프로세스를 향상시킬 수 있습니다"

"A IA pode aprimorar os processos de coleta, análise, previsão e avaliação de dados"

«ИИ может улучшить процессы сбора, анализа, прогнозирования и оценки данных»

"Yapay zeka veri toplama, analiz, tahmin ve değerlendirme süreçlerini geliştirebilir"

"AI có thể tăng cường quá trình thu thập, phân tích, dự đoán và đánh giá dữ liệu"

“人工智能可以增强数据收集、分析、预测和评估过程”

Authors:
(1) Zane Weissman, Worcester Polytechnic Institute Worcester, MA, USA {zweissman@wpi.edu};
(2) Thomas Eisenbarth, University of Lübeck Lübeck, S-H, Germany {thomas.eisenbarth@uni-luebeck.de};
(3) Thore Tiemann, University of Lübeck Lübeck, S-H, Germany {t.tiemann@uni-luebeck.de};
(4) Berk Sunar, Worcester Polytechnic Institute Worcester, MA, USA {sunar@wpi.edu}. Table of Links Abstract and Introduction
Background
Threat Models
Analysis of Firecracker's Containment Systems
Analysis of Microarchitectural Attack and Defenses in Firecracker Microvms
Conclusion, Acknowledgments, and References 3. THREAT MODELS We propose two threat models applicable to Firecracker-based serverless cloud systems: (1) The user-to-user model (Figure 3): a malicious user runs arbitrary code sandboxed within a Firecracker VM and attempts to leak data, inject data, or otherwise gain information about or control over another user’s sandboxed application. In this model, we consider (a) the time-sliced sharing of hardware, where the instances of the two users execute in turns on the CPU core, and (b) physical co-location, where the two users’ code runs concurrently on hardware that is shared in one way or another (for example, two cores on the same CPU or two threads in the same core if SMT is enabled). (2) The user-to-host model (Figure 4): a malicious user targets some component of the host system: the Firecracker VMM, KVM, or another part of the host system kernel. For this scenario, we only consider time-sliced sharing of hardware resources. This is because the host only executes code if the guest user’s VM exits, e. g. due to a page fault that has to be handled by the host kernel or VMM. For both models, we assume that a malicious user is able to control the runtime environment of its application. In our models, malicious users do not posses guest kernel privileges. Therefore, both models grant the attacker slightly less privileges than the model assumed by [1] where the guest kernel is chosen and configured by the VMM but assumed to be compromised at runtime. Rather, the attacker’s capabilities in our models match the capabilities granted to users in deployments of Firecracker in AWS Lambda and Fargate. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. Authors: (1) Zane Weissman, Worcester Polytechnic Institute Worcester, MA, USA {zweissman@wpi.edu}; (2) Thomas Eisenbarth, University of Lübeck Lübeck, S-H, Germany {thomas.eisenbarth@uni-luebeck.de}; (3) Thore Tiemann, University of Lübeck Lübeck, S-H, Germany {t.tiemann@uni-luebeck.de}; (4) Berk Sunar, Worcester Polytechnic Institute Worcester, MA, USA {sunar@wpi.edu}. Authors: Authors: (1) Zane Weissman, Worcester Polytechnic Institute Worcester, MA, USA {zweissman@wpi.edu}; (2) Thomas Eisenbarth, University of Lübeck Lübeck, S-H, Germany {thomas.eisenbarth@uni-luebeck.de}; (3) Thore Tiemann, University of Lübeck Lübeck, S-H, Germany {t.tiemann@uni-luebeck.de}; (4) Berk Sunar, Worcester Polytechnic Institute Worcester, MA, USA {sunar@wpi.edu}. Table of Links Abstract and Introduction Background Threat Models Analysis of Firecracker's Containment Systems Analysis of Microarchitectural Attack and Defenses in Firecracker Microvms Conclusion, Acknowledgments, and References Abstract and Introduction Abstract and Introduction Background Background Threat Models Threat Models Analysis of Firecracker's Containment Systems Analysis of Firecracker's Containment Systems Analysis of Microarchitectural Attack and Defenses in Firecracker Microvms Analysis of Microarchitectural Attack and Defenses in Firecracker Microvms Conclusion, Acknowledgments, and References Conclusion, Acknowledgments, and References 3. THREAT MODELS We propose two threat models applicable to Firecracker-based serverless cloud systems: (1) The user-to-user model (Figure 3): a malicious user runs arbitrary code sandboxed within a Firecracker VM and attempts to leak data, inject data, or otherwise gain information about or control over another user’s sandboxed application. In this model, we consider (a) the time-sliced sharing of hardware, where the instances of the two users execute in turns on the CPU core, and (b) physical co-location, where the two users’ code runs concurrently on hardware that is shared in one way or another (for example, two cores on the same CPU or two threads in the same core if SMT is enabled). (2) The user-to-host model (Figure 4): a malicious user targets some component of the host system: the Firecracker VMM, KVM, or another part of the host system kernel. For this scenario, we only consider time-sliced sharing of hardware resources. This is because the host only executes code if the guest user’s VM exits, e. g. due to a page fault that has to be handled by the host kernel or VMM. For both models, we assume that a malicious user is able to control the runtime environment of its application. In our models, malicious users do not posses guest kernel privileges. Therefore, both models grant the attacker slightly less privileges than the model assumed by [1] where the guest kernel is chosen and configured by the VMM but assumed to be compromised at runtime. Rather, the attacker’s capabilities in our models match the capabilities granted to users in deployments of Firecracker in AWS Lambda and Fargate. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. available on arxiv

Microarchitectural Security of AWS Firecracker VMM: Threat Models

AWS ফায়ারক্র্যাকার VMM এর মাইক্রোআর্কিটেকচারাল সিকিউরিটি: থ্রেট মডেল

Mikroarchitektonische Sicherheit von AWS Firecracker VMM: Bedrohungsmodelle

Seguridad microarquitectónica de AWS Firecracker VMM: modelos de amenazas

Sécurité microarchitecturale d'AWS Firecracker VMM : modèles de menace

AWS फायरक्रैकर VMM की माइक्रोआर्किटेक्चरल सुरक्षा: ख़तरा मॉडल

AWS Firecracker VMM のマイクロアーキテクチャセキュリティ: 脅威モデル

AWS Firecracker VMM의 마이크로아키텍처 보안: 위협 모델

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

Микроархитектурная безопасность AWS Firecracker VMM: модели угроз

AWS Firecracker VMM'nin Mikro Mimari Güvenliği: Tehdit Modelleri

Bảo mật vi kiến trúc của AWS Firecracker VMM: Mô hình mối đe dọa

AWS Firecracker VMM 的微架构安全性：威胁模型

Microarchitectural Security of AWS Firecracker VMM: Analysis of Microarchitectural Attack & Defenses

AWS ফায়ারক্র্যাকার VMM এর মাইক্রোআর্কিটেকচারাল সিকিউরিটি: মাইক্রোআর্কিটেকচারাল অ্যাটাক এবং ডিফেন্সের বিশ্লেষণ

Mikroarchitektonische Sicherheit von AWS Firecracker VMM: Analyse von mikroarchitektonischen Angriffen und Abwehrmaßnahmen

Seguridad microarquitectónica de AWS Firecracker VMM: análisis de ataques y defensas microarquitectónicas

Sécurité microarchitecturale d'AWS Firecracker VMM : analyse des attaques et des défenses microarchitecturales

AWS फायरक्रैकर VMM की माइक्रोआर्किटेक्चरल सुरक्षा: माइक्रोआर्किटेक्चरल हमले और बचाव का विश्लेषण

AWS Firecracker VMM のマイクロアーキテクチャセキュリティ: マイクロアーキテクチャ攻撃と防御の分析

AWS Firecracker VMM의 마이크로아키텍처 보안: 마이크로아키텍처 공격 및 방어 분석

Segurança microarquitetônica do AWS Firecracker VMM: análise de ataques e defesas microarquitetônicas

Микроархитектурная безопасность AWS Firecracker VMM: анализ микроархитектурных атак и защиты

AWS Firecracker VMM'nin Mikro Mimari Güvenliği: Mikro Mimari Saldırı ve Savunmaların Analizi

Bảo mật vi kiến trúc của AWS Firecracker VMM: Phân tích tấn công và phòng thủ vi kiến trúc

AWS Firecracker VMM 微架构安全：微架构攻击与防御分析

Microarchitectural Security of AWS Firecracker VMM: Background

AWS ফায়ারক্র্যাকার VMM এর মাইক্রোআর্কিটেকচারাল নিরাপত্তা: পটভূমি

Mikroarchitektonische Sicherheit von AWS Firecracker VMM: Hintergrund

Seguridad microarquitectónica de AWS Firecracker VMM: antecedentes

Sécurité microarchitecturale d'AWS Firecracker VMM : contexte

AWS फायरक्रैकर VMM की माइक्रोआर्किटेक्चरल सुरक्षा: पृष्ठभूमि

AWS Firecracker VMM のマイクロアーキテクチャセキュリティ: 背景

AWS Firecracker VMM의 마이크로아키텍처 보안: 배경

Segurança microarquitetônica do AWS Firecracker VMM: histórico

Микроархитектурная безопасность AWS Firecracker VMM: предыстория

AWS Firecracker VMM'nin Mikro Mimari Güvenliği: Arka Plan

Bảo mật vi kiến trúc của AWS Firecracker VMM: Bối cảnh

AWS Firecracker VMM 的微架构安全性：背景

Authors:
(1) Zane Weissman, Worcester Polytechnic Institute Worcester, MA, USA {zweissman@wpi.edu};
(2) Thomas Eisenbarth, University of Lübeck Lübeck, S-H, Germany {thomas.eisenbarth@uni-luebeck.de};
(3) Thore Tiemann, University of Lübeck Lübeck, S-H, Germany {t.tiemann@uni-luebeck.de};
(4) Berk Sunar, Worcester Polytechnic Institute Worcester, MA, USA {sunar@wpi.edu}. Table of Links Abstract and Introduction
Background
Threat Models
Analysis of Firecracker's Containment Systems
Analysis of Microarchitectural Attack and Defenses in Firecracker Microvms
Conclusion, Acknowledgments, and References 4. ANALYSIS OF FIRECRACKER’S CONTAINMENT SYSTEMS Figure 2 shows the containment offered by Firecracker, as presented by AWS. In this section, we analyze each depicted component and their defenses against and vulnerabilities to microarchitectural attacks KVM. Linux kernel-based virtual machine (KVM) is the hypervisor implemented in modern Linux kernels and therefore part of the Linux code base. It virtualizes the supervisor and user modes of the underlying hardware, manages context switches between VMs, and handles most VM-exit reasons unless they are related to I/O operations. Besides these architectural isolation mechanisms, KVM also implements mitigations against Spectre attacks on a VM-exit to protect the host OS or hypervisor from malicious guests. Firecracker heavily relies on KVM as its hypervisor. However, since KVM is part of the Linux source code and developed by the Linux community, we define KVM to not be a part of Firecracker. Therefore, countermeasures against microarchitectural attacks that are implemented in KVM cannot be attributed to Firecracker’s containment system. Metadata, device, and I/O services. The metadata, device, and I/O services are the parts of the Firecracker VMM and API that interact directly with a VM, collecting and managing metrics and providing connectivity. AWS touts the simplicity of these interfaces (for a reduced attack surface) and that they are written from scratch for Firecracker in Rust, a programming language known for its security features [9]. However, Rust most notably provides in-process protection against invalid and out-of-bounds memory accesses, but microarchitectural attacks like cache attacks, Spectre, and MDS can leak information between processes rather than directly hijacking a victim’s process. Another notable difference between Firecracker and many other VMMs is that all of these services are run within the same host process as the VM itself, albeit in another thread. While the virtualization of memory addresses within the VM provides some obfuscation between the guest’s code and the I/O services, some Spectre attacks work specifically within a single process. Intraprocess attacks may pose less of a threat to real world systems, however, since two guests running on the same hardware each have their own copy of these essential services. Jailer barrier. In the event that the API or VMM are compromised, the jailer provides one last barrier of defense around a Firecracker instance. It protects the host system’s files and resources with namespaces and control groups (cgroups), respectively [7]. Microarchitectural attacks do not directly threaten files, which are by definition outside of the microarchitectural state. Cgroups allow a system administrator to assign processes to groups and then allocate, constrain, and monitor system resource usage on a per-group basis [17]. It is plausible that limitations applied with cgroups could impede an attacker’s ability to carry out certain microarchitectural attacks. For example, memory limitations might make it difficult to carry out eviction-based cache attacks, or CPU time limitations could prevent an attacker from making effective use of a CPU denial-of-service tool like HyperDegrade [2] which can slow down a victim process, simplifying the timing of a microarchitectural side-channel exfiltration or injection. In practice, Firecracker is not distributed with any particular cgroup rules [7]; in fact, it is specifically designed for the efficient operation of many Firecracker VMs under the default Linux resource allocation [6]. None of the isolation and containment systems in Firecracker seem to directly protect against user-to-user or user-to-host attacks. Therefore, we proceeded to test various microarchitectural attack proof of concepts inside and outside of Firecracker VMs. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. Authors: (1) Zane Weissman, Worcester Polytechnic Institute Worcester, MA, USA {zweissman@wpi.edu}; (2) Thomas Eisenbarth, University of Lübeck Lübeck, S-H, Germany {thomas.eisenbarth@uni-luebeck.de}; (3) Thore Tiemann, University of Lübeck Lübeck, S-H, Germany {t.tiemann@uni-luebeck.de}; (4) Berk Sunar, Worcester Polytechnic Institute Worcester, MA, USA {sunar@wpi.edu}. Authors: Authors: (1) Zane Weissman, Worcester Polytechnic Institute Worcester, MA, USA {zweissman@wpi.edu}; (2) Thomas Eisenbarth, University of Lübeck Lübeck, S-H, Germany {thomas.eisenbarth@uni-luebeck.de}; (3) Thore Tiemann, University of Lübeck Lübeck, S-H, Germany {t.tiemann@uni-luebeck.de}; (4) Berk Sunar, Worcester Polytechnic Institute Worcester, MA, USA {sunar@wpi.edu}. Table of Links Abstract and Introduction Background Threat Models Analysis of Firecracker's Containment Systems Analysis of Microarchitectural Attack and Defenses in Firecracker Microvms Conclusion, Acknowledgments, and References Abstract and Introduction Abstract and Introduction Background Background Threat Models Threat Models Analysis of Firecracker's Containment Systems Analysis of Firecracker's Containment Systems Analysis of Microarchitectural Attack and Defenses in Firecracker Microvms Analysis of Microarchitectural Attack and Defenses in Firecracker Microvms Conclusion, Acknowledgments, and References Conclusion, Acknowledgments, and References 4. ANALYSIS OF FIRECRACKER’S CONTAINMENT SYSTEMS Figure 2 shows the containment offered by Firecracker, as presented by AWS. In this section, we analyze each depicted component and their defenses against and vulnerabilities to microarchitectural attacks KVM . Linux kernel-based virtual machine (KVM) is the hypervisor implemented in modern Linux kernels and therefore part of the Linux code base. It virtualizes the supervisor and user modes of the underlying hardware, manages context switches between VMs, and handles most VM-exit reasons unless they are related to I/O operations. Besides these architectural isolation mechanisms, KVM also implements mitigations against Spectre attacks on a VM-exit to protect the host OS or hypervisor from malicious guests. Firecracker heavily relies on KVM as its hypervisor. However, since KVM is part of the Linux source code and developed by the Linux community, we define KVM to not be a part of Firecracker. Therefore, countermeasures against microarchitectural attacks that are implemented in KVM cannot be attributed to Firecracker’s containment system. KVM Metadata, device, and I/O services. The metadata, device, and I/O services are the parts of the Firecracker VMM and API that interact directly with a VM, collecting and managing metrics and providing connectivity. AWS touts the simplicity of these interfaces (for a reduced attack surface) and that they are written from scratch for Firecracker in Rust, a programming language known for its security features [9]. However, Rust most notably provides in-process protection against invalid and out-of-bounds memory accesses, but microarchitectural attacks like cache attacks, Spectre, and MDS can leak information between processes rather than directly hijacking a victim’s process. Metadata, device, and I/O services. Another notable difference between Firecracker and many other VMMs is that all of these services are run within the same host process as the VM itself, albeit in another thread. While the virtualization of memory addresses within the VM provides some obfuscation between the guest’s code and the I/O services, some Spectre attacks work specifically within a single process. Intraprocess attacks may pose less of a threat to real world systems, however, since two guests running on the same hardware each have their own copy of these essential services. Jailer barrier. In the event that the API or VMM are compromised, the jailer provides one last barrier of defense around a Firecracker instance. It protects the host system’s files and resources with namespaces and control groups (cgroups), respectively [7]. Microarchitectural attacks do not directly threaten files, which are by definition outside of the microarchitectural state. Cgroups allow a system administrator to assign processes to groups and then allocate, constrain, and monitor system resource usage on a per-group basis [17]. It is plausible that limitations applied with cgroups could impede an attacker’s ability to carry out certain microarchitectural attacks. For example, memory limitations might make it difficult to carry out eviction-based cache attacks, or CPU time limitations could prevent an attacker from making effective use of a CPU denial-of-service tool like HyperDegrade [2] which can slow down a victim process, simplifying the timing of a microarchitectural side-channel exfiltration or injection. In practice, Firecracker is not distributed with any particular cgroup rules [7]; in fact, it is specifically designed for the efficient operation of many Firecracker VMs under the default Linux resource allocation [6]. Jailer barrier. None of the isolation and containment systems in Firecracker seem to directly protect against user-to-user or user-to-host attacks. Therefore, we proceeded to test various microarchitectural attack proof of concepts inside and outside of Firecracker VMs. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. available on arxiv

Microarchitectural Security of AWS Firecracker VMM: Analysis of Firecracker's Containment Systems

AWS ফায়ারক্র্যাকার VMM এর মাইক্রোআর্কিটেকচারাল সিকিউরিটি: ফায়ারক্র্যাকারের কন্টেনমেন্ট সিস্টেমের বিশ্লেষণ

Mikroarchitektonische Sicherheit von AWS Firecracker VMM: Analyse der Eindämmungssysteme von Firecracker

Seguridad microarquitectónica de AWS Firecracker VMM: análisis de los sistemas de contención de Firecracker

Sécurité microarchitecturale d'AWS Firecracker VMM : analyse des systèmes de confinement de Firecracker

AWS फायरक्रैकर VMM की माइक्रोआर्किटेक्चरल सुरक्षा: फायरक्रैकर की कंटेनमेंट प्रणालियों का विश्लेषण

AWS Firecracker VMM のマイクロアーキテクチャセキュリティ: Firecracker の封じ込めシステムの分析

AWS Firecracker VMM의 마이크로아키텍처 보안: Firecracker의 격리 시스템 분석

Segurança microarquitetônica do AWS Firecracker VMM: análise dos sistemas de contenção do Firecracker

Микроархитектурная безопасность AWS Firecracker VMM: анализ систем сдерживания фейерверка

AWS Firecracker VMM'nin Mikro Mimari Güvenliği: Firecracker'ın Muhafaza Sistemlerinin Analizi

Bảo mật vi kiến trúc của AWS Firecracker VMM: Phân tích hệ thống ngăn chặn pháo hoa

AWS Firecracker VMM 的微架构安全性：Firecracker 遏制系统分析

Microarchitectural Security of AWS Firecracker VMM: Conclusion, Acknowledgments, and References

AWS ফায়ারক্র্যাকার VMM এর মাইক্রোআর্কিটেকচারাল নিরাপত্তা: উপসংহার, স্বীকৃতি এবং রেফারেন্স

Mikroarchitektonische Sicherheit von AWS Firecracker VMM: Fazit, Danksagungen und Referenzen

Seguridad microarquitectónica de AWS Firecracker VMM: conclusión, reconocimientos y referencias

Sécurité microarchitecturale d'AWS Firecracker VMM : conclusion, remerciements et références

AWS फायरक्रैकर VMM की माइक्रोआर्किटेक्चरल सुरक्षा: निष्कर्ष, आभार और संदर्भ

AWS Firecracker VMM のマイクロアーキテクチャセキュリティ: 結論、謝辞、参考文献

AWS Firecracker VMM의 마이크로아키텍처 보안: 결론, 승인 및 참조

Segurança microarquitetônica do AWS Firecracker VMM: conclusão, agradecimentos e referências

Микроархитектурная безопасность AWS Firecracker VMM: заключение, благодарности и ссылки

AWS Firecracker VMM'nin Mikro Mimari Güvenliği: Sonuç, Teşekkür ve Referanslar

Bảo mật vi kiến trúc của AWS Firecracker VMM: Kết luận, Lời cảm ơn và Tài liệu tham khảo

AWS Firecracker VMM 的微架构安全性：结论、致谢和参考文献

Microarchitectural Security of AWS Firecracker VMM: Abstract & Intro

AWS ফায়ারক্র্যাকার VMM এর মাইক্রোআর্কিটেকচারাল নিরাপত্তা: বিমূর্ত এবং ভূমিকা

Mikroarchitektonische Sicherheit von AWS Firecracker VMM: Zusammenfassung und Einführung

Seguridad microarquitectónica de AWS Firecracker VMM: resumen e introducción

Sécurité microarchitecturale d'AWS Firecracker VMM : résumé et introduction

AWS फायरक्रैकर VMM की माइक्रोआर्किटेक्चरल सुरक्षा: सार और परिचय

AWS Firecracker VMM のマイクロアーキテクチャセキュリティ: 概要と概要

AWS Firecracker VMM의 마이크로아키텍처 보안: 개요 및 소개

Segurança microarquitetônica do AWS Firecracker VMM: resumo e introdução

Микроархитектурная безопасность AWS Firecracker VMM: Аннотация и введение

AWS Firecracker VMM'nin Mikro Mimari Güvenliği: Özet ve Giriş

Bảo mật vi kiến trúc của AWS Firecracker VMM: Tóm tắt & Giới thiệu

AWS Firecracker VMM 的微架构安全性：摘要和简介

Finding AI-Generated Faces in the Wild: Discussion, Acknowledgements, and References

বন্যের মধ্যে এআই-উত্পন্ন মুখগুলি সন্ধান করা: আলোচনা, স্বীকৃতি এবং উল্লেখ

KI-generierte Gesichter in freier Wildbahn finden: Diskussion, Danksagungen und Referenzen

Encontrar rostros generados por IA en la naturaleza: debates, agradecimientos y referencias

Trouver des visages générés par l'IA dans la nature : discussion, remerciements et références

जंगल में एआई-जनरेटेड चेहरे खोजना: चर्चा, आभार और संदर्भ

AI 生成の顔の発見: 議論、謝辞、参考文献

야생에서 AI가 생성한 얼굴 찾기: 토론, 감사의 말, 참고자료

Encontrando rostos gerados por IA na natureza: discussão, agradecimentos e referências

Поиск лиц, созданных искусственным интеллектом, в дикой природе: обсуждение, благодарности и ссылки

Vahşi Doğada Yapay Zeka Tarafından Üretilen Yüzleri Bulma: Tartışma, Teşekkür ve Referanslar

Tìm kiếm khuôn mặt do AI tạo ra trong thế giới hoang dã: Thảo luận, Lời cảm ơn và Tài liệu tham khảo

在野外寻找人工智能生成的人脸：讨论、致谢和参考文献

Author:
(1) CALLA TSCHANZ. Table of Links Abstract and Intro
Background on tropical perspective
The expanded construction
GIT stability
Stack perspective
The canonical moduli stack
References References [AK16] Jarod Alper and Andrew Kresch. “Equivariant versal deformations of semistable curves”. In: Michigan Math. J. 65.2 (2016), pp. 227–250. [EH00] David Eisenbud and Joe Harris. The geometry of schemes. Vol. 197. Graduate Texts in Mathematics. Springer-Verlag, New York, 2000, pp. x+294. [FKX17] Tommaso de Fernex, J´anos Koll´ar, and Chenyang Xu. “The dual complex of singularities”. In: Higher dimensional algebraic geometry—in honour of Professor Yujiro Kawamata’s sixtieth birthday. Vol. 74. Adv. Stud. Pure Math. Math. Soc. Japan, Tokyo, 2017, pp. 103–129. [GHH15] Martin G. Gulbrandsen, Lars H. Halle, and Klaus Hulek. “A relative HilbertMumford criterion”. In: Manuscripta Math. 148.3-4 (2015), pp. 283–301. [GHH19] Martin G. Gulbrandsen, Lars H. Halle, and Klaus Hulek. “A GIT construction of degenerations of Hilbert schemes of points”. In: Doc. Math. 24 (2019), pp. 421–472. [Ken23] Patrick Kennedy-Hunt. The Logarithmic Quot space: foundations and tropicalisation. 2023. arXiv: 2308.14470 [math.AG]. [KLSV18] J´anos Koll´ar, Radu Laza, Giulia Sacc`a, and Claire Voisin. “Remarks on degenerations of hyper-K¨ahler manifolds”. In: Ann. Inst. Fourier (Grenoble) 68.7 (2018), pp. 2837–2882. [Li13] Jun Li. “Good degenerations of moduli spaces”. In: Handbook of moduli. Vol. II. Vol. 25. Adv. Lect. Math. (ALM). Int. Press, Somerville, MA, 2013, pp. 299–351. [Log] Dan Abramovich, Qile Chen, Danny Gillam, Yuhao Huang, Martin Olsson, Matthew Satriano, and Shenghao Sun. “Logarithmic geometry and moduli”. In: Handbook of moduli. Vol. I. Vol. 24. Adv. Lect. Math. (ALM). Int. Press, Somerville, MA, 2013, pp. 1–61. [LW15] Jun Li and Baosen Wu. “Good degeneration of Quot-schemes and coherent systems”. In: Comm. Anal. Geom. 23.4 (2015), pp. 841–921. [MFK94] David Mumford, John Fogarty, and Frances Kirwan. Geometric invariant theory. Vol. 34. Ergebnisse der Mathematik und ihrer Grenzgebiete (2). Berlin: Springer Berlin, Heidelberg, 1994. [MR20] Davesh Maulik and Dhruv Ranganathan. Logarithmic Donaldson–Thomas theory. 2020. url: arXiv:2006.06603v2. [Nag08] Yasunari Nagai. “On monodromies of a degeneration of irreducible symplectic K¨ahler manifolds”. In: Math. Z. 258.2 (2008), pp. 407–426. [Ran22a] Dhruv Ranganathan. “Logarithmic and tropical moduli theory”. Notes for GAeL lecture course. June 2022. url: https://www.dpmms.cam.ac.uk/~dr508/GAeL2022.p [Ran22b] Dhruv Ranganathan. “Logarithmic Gromov-Witten theory with expansions”. In: Algebr. Geom. 9.6 (2022), pp. 714–761. 4 [Tev07] Jenia Tevelev. “Compactifications of subvarieties of tori”. In: Amer. J. Math. 129.4 (2007), pp. 1087–1104. This paper is available on arxiv under CC 4.0 license. Author: (1) CALLA TSCHANZ. Author: Author: (1) CALLA TSCHANZ. Table of Links Abstract and Intro Background on tropical perspective The expanded construction GIT stability Stack perspective The canonical moduli stack References Abstract and Intro Abstract and Intro Background on tropical perspective Background on tropical perspective The expanded construction The expanded construction GIT stability GIT stability Stack perspective Stack perspective The canonical moduli stack The canonical moduli stack References References References [AK16] Jarod Alper and Andrew Kresch. “Equivariant versal deformations of semistable curves”. In: Michigan Math. J. 65.2 (2016), pp. 227–250. [EH00] David Eisenbud and Joe Harris. The geometry of schemes. Vol. 197. Graduate Texts in Mathematics. Springer-Verlag, New York, 2000, pp. x+294. [FKX17] Tommaso de Fernex, J´anos Koll´ar, and Chenyang Xu. “The dual complex of singularities”. In: Higher dimensional algebraic geometry—in honour of Professor Yujiro Kawamata’s sixtieth birthday. Vol. 74. Adv. Stud. Pure Math. Math. Soc. Japan, Tokyo, 2017, pp. 103–129. [GHH15] Martin G. Gulbrandsen, Lars H. Halle, and Klaus Hulek. “A relative HilbertMumford criterion”. In: Manuscripta Math. 148.3-4 (2015), pp. 283–301. [GHH19] Martin G. Gulbrandsen, Lars H. Halle, and Klaus Hulek. “A GIT construction of degenerations of Hilbert schemes of points”. In: Doc. Math. 24 (2019), pp. 421–472. [Ken23] Patrick Kennedy-Hunt. The Logarithmic Quot space: foundations and tropicalisation. 2023. arXiv: 2308.14470 [math.AG]. [KLSV18] J´anos Koll´ar, Radu Laza, Giulia Sacc`a, and Claire Voisin. “Remarks on degenerations of hyper-K¨ahler manifolds”. In: Ann. Inst. Fourier (Grenoble) 68.7 (2018), pp. 2837–2882. [Li13] Jun Li. “Good degenerations of moduli spaces”. In: Handbook of moduli. Vol. II. Vol. 25. Adv. Lect. Math. (ALM). Int. Press, Somerville, MA, 2013, pp. 299–351. [Log] Dan Abramovich, Qile Chen, Danny Gillam, Yuhao Huang, Martin Olsson, Matthew Satriano, and Shenghao Sun. “Logarithmic geometry and moduli”. In: Handbook of moduli. Vol. I. Vol. 24. Adv. Lect. Math. (ALM). Int. Press, Somerville, MA, 2013, pp. 1–61. [LW15] Jun Li and Baosen Wu. “Good degeneration of Quot-schemes and coherent systems”. In: Comm. Anal. Geom. 23.4 (2015), pp. 841–921. [MFK94] David Mumford, John Fogarty, and Frances Kirwan. Geometric invariant theory. Vol. 34. Ergebnisse der Mathematik und ihrer Grenzgebiete (2). Berlin: Springer Berlin, Heidelberg, 1994. [MR20] Davesh Maulik and Dhruv Ranganathan. Logarithmic Donaldson–Thomas theory. 2020. url: arXiv:2006.06603v2. [Nag08] Yasunari Nagai. “On monodromies of a degeneration of irreducible symplectic K¨ahler manifolds”. In: Math. Z. 258.2 (2008), pp. 407–426. [Ran22a] Dhruv Ranganathan. “Logarithmic and tropical moduli theory”. Notes for GAeL lecture course. June 2022. url: https://www.dpmms.cam.ac.uk/~dr508/GAeL2022.p [Ran22b] Dhruv Ranganathan. “Logarithmic Gromov-Witten theory with expansions”. In: Algebr. Geom. 9.6 (2022), pp. 714–761. 4 [Tev07] Jenia Tevelev. “Compactifications of subvarieties of tori”. In: Amer. J. Math. 129.4 (2007), pp. 1087–1104. This paper is available on arxiv under CC 4.0 license. This paper is available on arxiv under CC 4.0 license. available on arxiv

Expansions for Hilbert Schemes: References

হিলবার্ট স্কিমগুলির সম্প্রসারণ: রেফারেন্স

Erweiterungen für Hilbert-Schemata: Referenzen

Ampliaciones para esquemas de Hilbert: referencias

Extensions pour les schémas Hilbert : références

हिल्बर्ट योजनाओं का विस्तार: संदर्भ

ヒルベルトスキームの展開: 参考文献

힐베르트 체계의 확장: 참고자료

Expansões para esquemas de Hilbert: referências

Разложения схем Гильберта: ссылки.

Hilbert Şemaları için Genişletmeler: Referanslar

Mở rộng cho Lược đồ Hilbert: Tài liệu tham khảo

希尔伯特方案的扩展：参考文献

How a Herd of Models Challenges ChatGPT's Dominance: Conclusion, Discussion, and References

"When You Take VC Funding, the Clock Often Starts Ticking" Entrepreneur Jack Smith on Exiting Vungle

"আপনি যখন ভিসি ফান্ডিং নেন, ঘড়ি প্রায়শই টিক টিক শুরু করে" উদ্যোক্তা জ্যাক স্মিথ এক্সিটিং ভাংলে

„Wenn man VC-Finanzierung annimmt, beginnt die Uhr oft zu ticken“ – Unternehmer Jack Smith über den Ausstieg aus Vungle

"Cuando se obtiene financiación de capital de riesgo, el tiempo a menudo empieza a correr" El empresario Jack Smith habla sobre su salida de Vungle

"Lorsque vous prenez un financement en capital-risque, le temps commence souvent à tourner" L'entrepreneur Jack Smith à propos de sa sortie de Vungle

"जब आप वी.सी. फंडिंग लेते हैं, तो अक्सर समय की गति बढ़ने लगती है" उद्यमी जैक स्मिथ ने वुंगल से बाहर निकलने पर कहा

「VC から資金を調達すると、時間が刻々と動き始めることが多い」起業家ジャック・スミスが Vungle からの撤退について語る

"VC 자금 지원을 받으면 시계가 똑딱거리기 시작하는 경우가 많습니다." 기업가 Jack Smith, Vungle 종료

“Quando você recebe financiamento de capital de risco, o relógio geralmente começa a contar” Empreendedor Jack Smith sobre a saída do Vungle

«Когда вы берете венчурное финансирование, часы часто начинают тикать» Предприниматель Джек Смит о выходе из Vungle

Girişimci Jack Smith, Vungle'dan Çıkış Konusunda "VC Finansmanı Aldığınızda Zaman Sıklıkla İşlemeye Başlıyor"

"Khi bạn nhận tiền từ VC, đồng hồ thường bắt đầu tích tắc" Doanh nhân Jack Smith khi rời khỏi Vũngle

“当你接受风险投资时，时钟通常开始滴答作响”企业家杰克·史密斯谈退出 Vungle

Four Thousand Years of Blood, Snot, and Tears

চার হাজার বছরের রক্ত, স্নোট এবং অশ্রু

Viertausend Jahre Blut, Rotz und Tränen

Cuatro mil años de sangre, mocos y lágrimas

Quatre mille ans de sang, de morve et de larmes

चार हज़ार साल का खून, बलगम और आँसू

Stories, News & Mentions about EISEN

Eisen’s Stories on HackerNoon