You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/cloud-services/cloud-services-allocation-failures.md
-2Lines changed: 0 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -18,8 +18,6 @@ ms.custom: compute-evergreen
18
18
19
19
When you deploy instances to a Cloud Service or add new web or worker role instances, Microsoft Azure allocates compute resources. You may occasionally receive errors when performing these operations even before you reach the Azure subscription limits. This article explains the causes of some of the common allocation failures and suggests possible remediation. The information can also be useful when you plan the deployment of your services.
The servers in Azure datacenters are partitioned into clusters. A new cloud service allocation request is attempted in multiple clusters. When the first instance is deployed to a cloud service(in either staging or production), that cloud service gets pinned to a cluster. Any further deployments for the cloud service happen in the same cluster. In this article, we refer to this state as "pinned to a cluster." The following diagram illustrates the case of a normal allocation, which is attempted in multiple clusters. The second diagram illustrates the case of an allocation pinned to Cluster 2 because that's where the existing Cloud Service CS_1 is hosted.
Copy file name to clipboardExpand all lines: articles/cloud-services/cloud-services-troubleshoot-common-issues-which-cause-roles-recycle.md
-2Lines changed: 0 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,8 +16,6 @@ ms.custom: compute-evergreen
16
16
17
17
This article discusses some of the common causes of deployment problems and provides troubleshooting tips to help you resolve these problems. An indication that a problem exists with an application is when the role instance fails to start, or it cycles between the initializing, busy, and stopping states.
If a role in your application relies on any assembly that isn't part of the .NET Framework or the Azure managed library, you must explicitly include that assembly in the application package. Keep in mind that other Microsoft frameworks aren't available on Azure by default. If your role relies on such a framework, you must add those assemblies to the application package.
Copy file name to clipboardExpand all lines: articles/cloud-services/cloud-services-troubleshoot-default-temp-folder-size-too-small-web-worker-role.md
-2Lines changed: 0 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,8 +17,6 @@ ms.custom: compute-evergreen
17
17
18
18
The default temporary directory of a cloud service worker or web role has a maximum size of 100 MB, which may become full at some point. This article describes how to avoid running out of space for the temporary directory.
The standard Windows environment variables TEMP and TMP are available to code that is running in your application. Both TEMP and TMP point to a single directory that has a maximum size of 100 MB. Any data stored in this directory isn't persisted across the lifecycle of the cloud service. If the role instances in a cloud service are recycled, the directory is cleaned.
## Problem: I can't access my website, but my deployment is started and all role instances are ready
31
29
The website URL link shown in the portal doesn't include the port. The default port for websites is 80. If your application is configured to run in a different port, you must add the correct port number to the URL when accessing the website.
Unresponsive roles and roles that are cycling between **Initializing**, **Busy**, and **Stopping** states can be caused by missing dynamic link libraries (DLLs) or assemblies.
Copy file name to clipboardExpand all lines: articles/cloud-services/mitigate-se.md
+149-2Lines changed: 149 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,8 +14,155 @@ ms.author: jushiman
14
14
ms.custom: compute-evergreen
15
15
---
16
16
17
+
# Guidance to mitigate speculative execution side-channel vulnerabilities in Azure
17
18
19
+
This article provides guidance for a new class of silicon based micro-architectural and speculative execution side-channel vulnerabilities that affect many modern processors and operating systems. This includes Intel, AMD, and ARM. Specific details for these silicon-based vulnerabilities can be found in the following security advisories and CVEs:
20
+
-[ADV180002 - Guidance to mitigate speculative execution side-channel vulnerabilities](https://msrc.microsoft.com/update-guide/vulnerability/ADV180002)
21
+
-[ADV180012 - Microsoft Guidance for Speculative Store Bypass](https://msrc.microsoft.com/update-guide/vulnerability/ADV180012)
22
+
-[ADV180013 - Microsoft Guidance for Rogue System Register Read](https://msrc.microsoft.com/update-guide/vulnerability/ADV180013)
23
+
-[ADV180016 - Microsoft Guidance for Lazy FP State Restore](https://msrc.microsoft.com/update-guide/vulnerability/ADV180016)
24
+
-[ADV180018 - Microsoft Guidance to mitigate L1TF variant](https://msrc.microsoft.com/update-guide/vulnerability/ADV180018)
25
+
-[ADV190013 - Microsoft Guidance to mitigate Microarchitectural Data Sampling vulnerabilities](https://msrc.microsoft.com/update-guide/vulnerability/ADV190013)
26
+
-[ADV220002 - Microsoft Guidance on Intel Processor MMIO Stale Data Vulnerabilities](https://msrc.microsoft.com/update-guide/vulnerability/ADV220002)
27
+
-[CVE-2022-23816 - AMD CPU Branch Type Confusion](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-23816)
28
+
-[CVE-2022-21123 - AMD CPU Branch Type Confusion](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-23825)
18
29
19
-
# Guidance to mitigate speculative execution side-channel vulnerabilities in Azure
The disclosure of these CPU vulnerabilities has resulted in questions from customers seeking more clarity.
32
+
33
+
Microsoft has deployed mitigations across all our cloud services. The infrastructure that runs Azure and isolates customer workloads from each other is protected. This means that a potential attacker using the same infrastructure can't attack your application using these vulnerabilities.
34
+
35
+
Azure is using [memory preserving maintenance](/azure/virtual-machines/maintenance-and-updates?bc=%2fazure%2fvirtual-machines%2fwindows%2fbreadcrumb%2ftoc.json%252c%2fazure%2fvirtual-machines%2fwindows%2fbreadcrumb%2ftoc.json&toc=%2fazure%2fvirtual-machines%2fwindows%2ftoc.json%253ftoc%253d%2fazure%2fvirtual-machines%2fwindows%2ftoc.json#maintenance-that-doesnt-require-a-reboot) whenever possible, to minimize customer impact and eliminate the need for reboots. Azure continues utilizing these methods when making systemwide updates to the host and protect our customers.
36
+
37
+
More information about how security is integrated into every aspect of Azure is available on the [Azure Security Documentation](/azure/security/index) site.
38
+
39
+
> [!NOTE]
40
+
> Since this document was first published, multiple variants of this vulnerability class have been disclosed. Microsoft continues to be heavily invested in protecting our customers and providing guidance. This page is updated as we continue to release further fixes.
41
+
>
42
+
> **Customers that are running untrusted code within their VM** need to take action to protect against these vulnerabilities by reading below for more guidance on all vulnerabilities.
43
+
>
44
+
> Other customers should evaluate these vulnerabilities from a Defense in Depth perspective and consider the security and performance implications of their chosen configuration.
45
+
>
46
+
47
+
48
+
49
+
## Keeping your operating systems up-to-date
50
+
51
+
While an OS update isn't required to isolate your applications running on Azure from other Azure customers, it is always a best practice to keep your software up-to-date. The latest Security Updates for Windows contain mitigations for these vulnerabilities. Similarly, Linux distributions have released multiple updates to address these vulnerabilities. Here are our recommended actions to update your operating system:
52
+
53
+
| Offering | Recommended Action |
54
+
|----------|---------------------|
55
+
| Azure Cloud Services | Enable [auto update](/azure/cloud-services/cloud-services-how-to-configure-portal) or ensure you're running the newest Guest OS. |
56
+
| Azure Linux Virtual Machines | Install updates from your operating system provider. For more information, see [Linux](#linux) later in this document. |
57
+
| Azure Windows Virtual Machines | Install the latest security rollup.
58
+
| Other Azure PaaS Services | There's no action needed for customers using these services. Azure automatically keeps your OS versions up-to-date. |
59
+
60
+
## Additional guidance if you're running untrusted code
61
+
62
+
Customers who allow untrusted users to execute arbitrary code may wish to implement some extra security features inside their Azure Virtual Machines or Cloud Services. These features protect against the intra-process disclosure vectors that several speculative execution vulnerabilities describe.
63
+
64
+
Example scenarios where more security features are recommended:
65
+
66
+
- You allow code that you don't trust to run inside your VM.
67
+
-*For example, you allow one of your customers to upload a binary or script that you then execute within your application*.
68
+
- You allow users that you don't trust to log into your VM using low privileged accounts.
69
+
-*For example, you allow a low-privileged user to log into one of your VMs using remote desktop or SSH*.
70
+
- You allow untrusted users access to virtual machines implemented via nested virtualization.
71
+
-*For example, you control the Hyper-V host, but allocate the VMs to untrusted users*.
72
+
73
+
Customers who don't implement a scenario involving untrusted code don't need to enable these extra security features.
74
+
75
+
## Enabling additional security
76
+
77
+
You can enable more security features inside your VM or Cloud Service if you're running untrusted code. In parallel, ensure your operating system is up-to-date to enable security features inside your VM or Cloud Service
78
+
79
+
### Windows
80
+
81
+
Your target operating system must be up-to-date to enable these extra security features. While numerous mitigations are enabled by default, the extra features described here must be enabled manually and may cause a performance impact.
82
+
83
+
84
+
85
+
#### Option 1
86
+
87
+
1. Follow the instructions in [KB4072698](https://support.microsoft.com/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution) to verify protections are enabled using the [SpeculationControl](https://aka.ms/SpeculationControlPS) PowerShell module.
88
+
89
+
> [!NOTE]
90
+
> If you previously downloaded this module, you need to install the newest version.
91
+
92
+
93
+
94
+
To validate enabled protections against these vulnerabilities, see [Understanding Get-SpeculationControlSettings PowerShell script output](https://support.microsoft.com/topic/understanding-get-speculationcontrolsettings-powershell-script-output-fd70a80a-a63f-e539-cda5-5be4c9e67c04).
95
+
96
+
If protections aren't enabled, please [contact Azure Support](https://aka.ms/microcodeenablementrequest-supporttechnical) to enable additional controls on your Azure VM.
97
+
98
+
1. To enable Kernel Virtual Address Shadowing (KVAS) and Branch Target Injection (BTI) OS support, follow the instructions in [KB4072698](https://support.microsoft.com/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution) to enable protections using the `Session Manager` registry keys. A reboot is required.
99
+
100
+
101
+
1. For deployments that are using [nested virtualization](/virtualization/hyper-v-on-windows/user-guide/nested-virtualization) (D3 and E3 only): These instructions apply inside the VM you're using as a Hyper-V host.
102
+
103
+
a. Follow the instructions in [KB4072698](https://support.microsoft.com/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution) to enable protections using the `MinVmVersionForCpuBasedMitigations` registry keys.
104
+
b. Set the hypervisor scheduler type to `Core` by following the instructions [here](/windows-server/virtualization/hyper-v/manage/manage-hyper-v-scheduler-types).
105
+
106
+
#### Option 2
107
+
108
+
**Disable hyper-threading on the VM** - Customers running untrusted code on a hyper-threaded VM might choose to disable hyper-threading or move to a non-hyper-threaded VM size. Reference [this doc](/azure/virtual-machines/acu) for a list of hyper-threaded VM sizes (where ratio of vCPU to Core is 2:1). To check if your VM has hyper-threading enabled, refer to the below script using the Windows command line from within the VM.
109
+
110
+
Type `wmic` to enter the interactive interface. Then type the following command to view the amount of physical and logical processors on the VM.
111
+
112
+
```
113
+
CPU Get NumberOfCores,NumberOfLogicalProcessors /Format:List
114
+
```
115
+
116
+
If the number of logical processors is greater than physical processors (cores), then hyper-threading is enabled. If you're running a hyper-threaded VM, [contact Azure Support](https://aka.ms/MicrocodeEnablementRequest-SupportTechnical) to get hyper-threading disabled. Once hyper-threading is disabled, support requires a full VM reboot. Refer to [Core count](#core-count) to understand why your VM core count decreased.
117
+
118
+
### Option 3
119
+
120
+
For [CVE-2022-23816](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-23816) and [CVE-2022-21123](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-23825) (AMD CPU Branch Type Confusion), follow both **Option 1** and **Option 2** above.
121
+
122
+
123
+
124
+
### Linux
125
+
126
+
Enabling the set of extra security features inside requires that the target operating system be fully up-to-date. Some mitigations will be enabled by default. The following section describes the features which are off by default and/or reliant on hardware support (microcode). Enabling these features may cause a performance impact. Reference your operating system provider's documentation for further instructions.
127
+
128
+
129
+
1. Disable hyper-threading on the VM** - Customers running untrusted code on a hyper-threaded VM will need to disable hyper-threading or move to a non-hyper-threaded VM. Reference [this doc](/azure/virtual-machines/acu) for a list of hyper-threaded VM sizes (where ratio of vCPU to Core is 2:1). To check if you're running a hyper-threaded VM, run the `lscpu` command in the Linux VM.
130
+
131
+
If `Thread(s) per core = 2`, then hyper-threading has been enabled.
132
+
133
+
If `Thread(s) per core = 1`, then hyper-threading has been disabled.
134
+
135
+
136
+
Sample output for a VM with hyper-threading enabled:
137
+
138
+
```console
139
+
CPU Architecture: x86_64
140
+
CPU op-mode(s): 32-bit, 64-bit
141
+
Byte Order: Little Endian
142
+
CPU(s): 8
143
+
On-line CPU(s) list: 0-7
144
+
Thread(s) per core: 2
145
+
Core(s) per socket: 4
146
+
Socket(s): 1
147
+
NUMA node(s): 1
148
+
149
+
```
150
+
151
+
If you're running a hyper-threaded VM, [contact Azure Support](https://aka.ms/MicrocodeEnablementRequest-SupportTechnical) to get hyper-threading disabled. Once hyper-threading is disabled, **support will require a full VM reboot**. Refer to [Core count](#core-count) to understand why your VM core count decreased.
152
+
153
+
154
+
155
+
1. To mitigate against any of the below CPU based memory vulnerabilities, refer to your operating system provider's documentation:
When a hyper-threaded VM is created, Azure allocates 2 threads per core - these are called vCPUs. When hyper-threading is disabled, Azure removes a thread and surfaces up single threaded cores (physical cores). The ratio of vCPU to CPU is 2:1, so once hyper-threading is disabled, the CPU count in the VM will appear to have decreased by half. For example, a D8_v3 VM is a hyper-threaded VM running on 8 vCPUs (2 threads per core x 4 cores). When hyper-threading is disabled, CPUs will drop to 4 physical cores with 1 thread per core.
165
+
166
+
## Next steps
167
+
168
+
For more information about how security is integrated into every aspect of Azure, see [Azure Security Documentation](/azure/security/index).
0 commit comments