요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
상태와 기본 host 보호
l1tf.rst:119-164sysfs 상태 조합과 항상 적용되는 host PTE inversion 보호를 정리합니다.
guest 완화 메커니즘
l1tf.rst:165-363VMENTER L1D flush, VCPU confinement, interrupt affinity, SMT 제어와 EPT 비활성화를 설명합니다.
command line과 KVM 제어
l1tf.rst:364-449`l1tf=` 및 `kvm-intel.vmentry_l1d_flush=` option의 전체 의미를 제공합니다.
환경별 선택과 기본값
l1tf.rst:450-615신뢰 수준·SMT·EPT 조합별 권장 완화, nested virtualization과 커널 기본 정책의 근거를 설명합니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
1
L1TF - L1 Terminal Fault
2
========================
4
L1 Terminal Fault is a hardware vulnerability which allows unprivileged
5
speculative access to data which is available in the Level 1 Data Cache
6
when the page table entry controlling the virtual address, which is used
7
for the access, has the Present bit cleared or other reserved bits set.
9
Affected processors
10
-------------------
12
This vulnerability affects a wide range of Intel processors. The
13
vulnerability is not present on:
15
- Processors from AMD, Centaur and other non Intel vendors
17
- Older processor models, where the CPU family is < 6
19
- A range of Intel ATOM processors (Cedarview, Cloverview, Lincroft,
20
Penwell, Pineview, Silvermont, Airmont, Merrifield)
22
- The Intel XEON PHI family
24
- Intel processors which have the ARCH_CAP_RDCL_NO bit set in the
25
IA32_ARCH_CAPABILITIES MSR. If the bit is set the CPU is not affected
26
by the Meltdown vulnerability either. These CPUs should become
27
available by end of 2018.
29
Whether a processor is affected or not can be read out from the L1TF
30
vulnerability file in sysfs. See :ref:`l1tf_sys_info`.
32
Related CVEs
33
------------
35
The following CVE entries are related to the L1TF vulnerability:
37
============= ================= ==============================
38
CVE-2018-3615 L1 Terminal Fault SGX related aspects
39
CVE-2018-3620 L1 Terminal Fault OS, SMM related aspects
40
CVE-2018-3646 L1 Terminal Fault Virtualization related aspects
41
============= ================= ==============================
43
Problem
44
-------
46
If an instruction accesses a virtual address for which the relevant page
47
table entry (PTE) has the Present bit cleared or other reserved bits set,
48
then speculative execution ignores the invalid PTE and loads the referenced
49
data if it is present in the Level 1 Data Cache, as if the page referenced
50
by the address bits in the PTE was still present and accessible.
52
While this is a purely speculative mechanism and the instruction will raise
53
a page fault when it is retired eventually, the pure act of loading the
54
data and making it available to other speculative instructions opens up the
55
opportunity for side channel attacks to unprivileged malicious code,
56
similar to the Meltdown attack.
58
While Meltdown breaks the user space to kernel space protection, L1TF
59
allows to attack any physical memory address in the system and the attack
60
works across all protection domains. It allows an attack of SGX and also
61
works from inside virtual machines because the speculation bypasses the
62
extended page table (EPT) protection mechanism.
65
Attack scenarios
66
----------------
68
1. Malicious user space
69
^^^^^^^^^^^^^^^^^^^^^^^
71
Operating Systems store arbitrary information in the address bits of a
72
PTE which is marked non present. This allows a malicious user space
73
application to attack the physical memory to which these PTEs resolve.
74
In some cases user-space can maliciously influence the information
75
encoded in the address bits of the PTE, thus making attacks more
76
deterministic and more practical.
78
The Linux kernel contains a mitigation for this attack vector, PTE
79
inversion, which is permanently enabled and has no performance
80
impact. The kernel ensures that the address bits of PTEs, which are not
81
marked present, never point to cacheable physical memory space.
83
A system with an up to date kernel is protected against attacks from
84
malicious user space applications.
86
2. Malicious guest in a virtual machine
87
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
89
The fact that L1TF breaks all domain protections allows malicious guest
90
OSes, which can control the PTEs directly, and malicious guest user
91
space applications, which run on an unprotected guest kernel lacking the
92
PTE inversion mitigation for L1TF, to attack physical host memory.
94
A special aspect of L1TF in the context of virtualization is symmetric
95
multi threading (SMT). The Intel implementation of SMT is called
96
HyperThreading. The fact that Hyperthreads on the affected processors
97
share the L1 Data Cache (L1D) is important for this. As the flaw allows
98
only to attack data which is present in L1D, a malicious guest running
99
on one Hyperthread can attack the data which is brought into the L1D by
100
the context which runs on the sibling Hyperthread of the same physical
101
core. This context can be host OS, host user space or a different guest.
103
If the processor does not support Extended Page Tables, the attack is
104
only possible, when the hypervisor does not sanitize the content of the
105
effective (shadow) page tables.
107
While solutions exist to mitigate these attack vectors fully, these
108
mitigations are not enabled by default in the Linux kernel because they
109
can affect performance significantly. The kernel provides several
110
mechanisms which can be utilized to address the problem depending on the
111
deployment scenario. The mitigations, their protection scope and impact
112
are described in the next sections.
114
The default mitigations and the rationale for choosing them are explained
115
at the end of this document. See :ref:`default_mitigations`.
117
.. _l1tf_sys_info:
119
L1TF system information
120
-----------------------
122
The Linux kernel provides a sysfs interface to enumerate the current L1TF
123
status of the system: whether the system is vulnerable, and which
124
mitigations are active. The relevant sysfs file is:
126
/sys/devices/system/cpu/vulnerabilities/l1tf
128
The possible values in this file are:
130
=========================== ===============================
131
'Not affected' The processor is not vulnerable
132
'Mitigation: PTE Inversion' The host protection is active
133
=========================== ===============================
135
If KVM/VMX is enabled and the processor is vulnerable then the following
136
information is appended to the 'Mitigation: PTE Inversion' part:
138
- SMT status:
140
===================== ================
141
'VMX: SMT vulnerable' SMT is enabled
142
'VMX: SMT disabled' SMT is disabled
143
===================== ================
145
- L1D Flush mode:
147
================================ ====================================
148
'L1D vulnerable' L1D flushing is disabled
150
'L1D conditional cache flushes' L1D flush is conditionally enabled
152
'L1D cache flushes' L1D flush is unconditionally enabled
153
================================ ====================================
155
The resulting grade of protection is discussed in the following sections.
158
Host mitigation mechanism
159
-------------------------
161
The kernel is unconditionally protected against L1TF attacks from malicious
162
user space running on the host.
165
Guest mitigation mechanisms
166
---------------------------
168
.. _l1d_flush:
170
1. L1D flush on VMENTER
171
^^^^^^^^^^^^^^^^^^^^^^^
173
To make sure that a guest cannot attack data which is present in the L1D
174
the hypervisor flushes the L1D before entering the guest.
176
Flushing the L1D evicts not only the data which should not be accessed
177
by a potentially malicious guest, it also flushes the guest
178
data. Flushing the L1D has a performance impact as the processor has to
179
bring the flushed guest data back into the L1D. Depending on the
180
frequency of VMEXIT/VMENTER and the type of computations in the guest
181
performance degradation in the range of 1% to 50% has been observed. For
182
scenarios where guest VMEXIT/VMENTER are rare the performance impact is
183
minimal. Virtio and mechanisms like posted interrupts are designed to
184
confine the VMEXITs to a bare minimum, but specific configurations and
185
application scenarios might still suffer from a high VMEXIT rate.
187
The kernel provides two L1D flush modes:
188
- conditional ('cond')
189
- unconditional ('always')
191
The conditional mode avoids L1D flushing after VMEXITs which execute
192
only audited code paths before the corresponding VMENTER. These code
193
paths have been verified that they cannot expose secrets or other
194
interesting data to an attacker, but they can leak information about the
195
address space layout of the hypervisor.
197
Unconditional mode flushes L1D on all VMENTER invocations and provides
198
maximum protection. It has a higher overhead than the conditional
199
mode. The overhead cannot be quantified correctly as it depends on the
200
workload scenario and the resulting number of VMEXITs.
202
The general recommendation is to enable L1D flush on VMENTER. The kernel
203
defaults to conditional mode on affected processors.
205
**Note**, that L1D flush does not prevent the SMT problem because the
206
sibling thread will also bring back its data into the L1D which makes it
207
attackable again.
209
L1D flush can be controlled by the administrator via the kernel command
210
line and sysfs control files. See :ref:`mitigation_control_command_line`
211
and :ref:`mitigation_control_kvm`.
213
.. _guest_confinement:
215
2. Guest VCPU confinement to dedicated physical cores
216
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
218
To address the SMT problem, it is possible to make a guest or a group of
219
guests affine to one or more physical cores. The proper mechanism for
220
that is to utilize exclusive cpusets to ensure that no other guest or
221
host tasks can run on these cores.
223
If only a single guest or related guests run on sibling SMT threads on
224
the same physical core then they can only attack their own memory and
225
restricted parts of the host memory.
227
Host memory is attackable, when one of the sibling SMT threads runs in
228
host OS (hypervisor) context and the other in guest context. The amount
229
of valuable information from the host OS context depends on the context
230
which the host OS executes, i.e. interrupts, soft interrupts and kernel
231
threads. The amount of valuable data from these contexts cannot be
232
declared as non-interesting for an attacker without deep inspection of
233
the code.
235
**Note**, that assigning guests to a fixed set of physical cores affects
236
the ability of the scheduler to do load balancing and might have
237
negative effects on CPU utilization depending on the hosting
238
scenario. Disabling SMT might be a viable alternative for particular
239
scenarios.
241
For further information about confining guests to a single or to a group
242
of cores consult the cpusets documentation:
244
https://www.kernel.org/doc/Documentation/admin-guide/cgroup-v1/cpusets.rst
246
.. _interrupt_isolation:
248
3. Interrupt affinity
249
^^^^^^^^^^^^^^^^^^^^^
251
Interrupts can be made affine to logical CPUs. This is not universally
252
true because there are types of interrupts which are truly per CPU
253
interrupts, e.g. the local timer interrupt. Aside of that multi queue
254
devices affine their interrupts to single CPUs or groups of CPUs per
255
queue without allowing the administrator to control the affinities.
257
Moving the interrupts, which can be affinity controlled, away from CPUs
258
which run untrusted guests, reduces the attack vector space.
260
Whether the interrupts with are affine to CPUs, which run untrusted
261
guests, provide interesting data for an attacker depends on the system
262
configuration and the scenarios which run on the system. While for some
263
of the interrupts it can be assumed that they won't expose interesting
264
information beyond exposing hints about the host OS memory layout, there
265
is no way to make general assumptions.
267
Interrupt affinity can be controlled by the administrator via the
268
/proc/irq/$NR/smp_affinity[_list] files. Limited documentation is
269
available at:
271
https://www.kernel.org/doc/Documentation/core-api/irq/irq-affinity.rst
273
.. _smt_control:
275
4. SMT control
276
^^^^^^^^^^^^^^
278
To prevent the SMT issues of L1TF it might be necessary to disable SMT
279
completely. Disabling SMT can have a significant performance impact, but
280
the impact depends on the hosting scenario and the type of workloads.
281
The impact of disabling SMT needs also to be weighted against the impact
282
of other mitigation solutions like confining guests to dedicated cores.
284
The kernel provides a sysfs interface to retrieve the status of SMT and
285
to control it. It also provides a kernel command line interface to
286
control SMT.
288
The kernel command line interface consists of the following options:
290
=========== ==========================================================
291
nosmt Affects the bring up of the secondary CPUs during boot. The
292
kernel tries to bring all present CPUs online during the
293
boot process. "nosmt" makes sure that from each physical
294
core only one - the so called primary (hyper) thread is
295
activated. Due to a design flaw of Intel processors related
296
to Machine Check Exceptions the non primary siblings have
297
to be brought up at least partially and are then shut down
298
again. "nosmt" can be undone via the sysfs interface.
300
nosmt=force Has the same effect as "nosmt" but it does not allow to
301
undo the SMT disable via the sysfs interface.
302
=========== ==========================================================
304
The sysfs interface provides two files:
306
- /sys/devices/system/cpu/smt/control
307
- /sys/devices/system/cpu/smt/active
309
/sys/devices/system/cpu/smt/control:
311
This file allows to read out the SMT control state and provides the
312
ability to disable or (re)enable SMT. The possible states are:
314
============== ===================================================
315
on SMT is supported by the CPU and enabled. All
316
logical CPUs can be onlined and offlined without
317
restrictions.
319
off SMT is supported by the CPU and disabled. Only
320
the so called primary SMT threads can be onlined
321
and offlined without restrictions. An attempt to
322
online a non-primary sibling is rejected
324
forceoff Same as 'off' but the state cannot be controlled.
325
Attempts to write to the control file are rejected.
327
notsupported The processor does not support SMT. It's therefore
328
not affected by the SMT implications of L1TF.
329
Attempts to write to the control file are rejected.
330
============== ===================================================
332
The possible states which can be written into this file to control SMT
333
state are:
335
- on
336
- off
337
- forceoff
339
/sys/devices/system/cpu/smt/active:
341
This file reports whether SMT is enabled and active, i.e. if on any
342
physical core two or more sibling threads are online.
344
SMT control is also possible at boot time via the l1tf kernel command
345
line parameter in combination with L1D flush control. See
346
:ref:`mitigation_control_command_line`.
348
5. Disabling EPT
349
^^^^^^^^^^^^^^^^
351
Disabling EPT for virtual machines provides full mitigation for L1TF even
352
with SMT enabled, because the effective page tables for guests are
353
managed and sanitized by the hypervisor. Though disabling EPT has a
354
significant performance impact especially when the Meltdown mitigation
355
KPTI is enabled.
357
EPT can be disabled in the hypervisor via the 'kvm-intel.ept' parameter.
359
There is ongoing research and development for new mitigation mechanisms to
360
address the performance impact of disabling SMT or EPT.
362
.. _mitigation_control_command_line:
364
Mitigation control on the kernel command line
365
---------------------------------------------
367
The kernel command line allows to control the L1TF mitigations at boot
368
time with the option "l1tf=". The valid arguments for this option are:
370
============ =============================================================
371
full Provides all available mitigations for the L1TF
372
vulnerability. Disables SMT and enables all mitigations in
373
the hypervisors, i.e. unconditional L1D flushing
375
SMT control and L1D flush control via the sysfs interface
376
is still possible after boot. Hypervisors will issue a
377
warning when the first VM is started in a potentially
378
insecure configuration, i.e. SMT enabled or L1D flush
379
disabled.
381
full,force Same as 'full', but disables SMT and L1D flush runtime
382
control. Implies the 'nosmt=force' command line option.
383
(i.e. sysfs control of SMT is disabled.)
385
flush Leaves SMT enabled and enables the default hypervisor
386
mitigation, i.e. conditional L1D flushing
388
SMT control and L1D flush control via the sysfs interface
389
is still possible after boot. Hypervisors will issue a
390
warning when the first VM is started in a potentially
391
insecure configuration, i.e. SMT enabled or L1D flush
392
disabled.
394
flush,nosmt Disables SMT and enables the default hypervisor mitigation,
395
i.e. conditional L1D flushing.
397
SMT control and L1D flush control via the sysfs interface
398
is still possible after boot. Hypervisors will issue a
399
warning when the first VM is started in a potentially
400
insecure configuration, i.e. SMT enabled or L1D flush
401
disabled.
403
flush,nowarn Same as 'flush', but hypervisors will not warn when a VM is
404
started in a potentially insecure configuration.
406
off Disables hypervisor mitigations and doesn't emit any
407
warnings.
408
It also drops the swap size and available RAM limit restrictions
409
on both hypervisor and bare metal.
411
============ =============================================================
413
The default is 'flush'. For details about L1D flushing see :ref:`l1d_flush`.
416
.. _mitigation_control_kvm:
418
Mitigation control for KVM - module parameter
419
-------------------------------------------------------------
421
The KVM hypervisor mitigation mechanism, flushing the L1D cache when
422
entering a guest, can be controlled with a module parameter.
424
The option/parameter is "kvm-intel.vmentry_l1d_flush=". It takes the
425
following arguments:
427
============ ==============================================================
428
always L1D cache flush on every VMENTER.
430
cond Flush L1D on VMENTER only when the code between VMEXIT and
431
VMENTER can leak host memory which is considered
432
interesting for an attacker. This still can leak host memory
433
which allows e.g. to determine the hosts address space layout.
435
never Disables the mitigation
436
============ ==============================================================
438
The parameter can be provided on the kernel command line, as a module
439
parameter when loading the modules and at runtime modified via the sysfs
440
file:
442
/sys/module/kvm_intel/parameters/vmentry_l1d_flush
444
The default is 'cond'. If 'l1tf=full,force' is given on the kernel command
445
line, then 'always' is enforced and the kvm-intel.vmentry_l1d_flush
446
module parameter is ignored and writes to the sysfs file are rejected.
448
.. _mitigation_selection:
450
Mitigation selection guide
451
--------------------------
453
1. No virtualization in use
454
^^^^^^^^^^^^^^^^^^^^^^^^^^^
456
The system is protected by the kernel unconditionally and no further
457
action is required.
459
2. Virtualization with trusted guests
460
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
462
If the guest comes from a trusted source and the guest OS kernel is
463
guaranteed to have the L1TF mitigations in place the system is fully
464
protected against L1TF and no further action is required.
466
To avoid the overhead of the default L1D flushing on VMENTER the
467
administrator can disable the flushing via the kernel command line and
468
sysfs control files. See :ref:`mitigation_control_command_line` and
469
:ref:`mitigation_control_kvm`.
472
3. Virtualization with untrusted guests
473
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
475
3.1. SMT not supported or disabled
476
""""""""""""""""""""""""""""""""""
478
If SMT is not supported by the processor or disabled in the BIOS or by
479
the kernel, it's only required to enforce L1D flushing on VMENTER.
481
Conditional L1D flushing is the default behaviour and can be tuned. See
482
:ref:`mitigation_control_command_line` and :ref:`mitigation_control_kvm`.
484
3.2. EPT not supported or disabled
485
""""""""""""""""""""""""""""""""""
487
If EPT is not supported by the processor or disabled in the hypervisor,
488
the system is fully protected. SMT can stay enabled and L1D flushing on
489
VMENTER is not required.
491
EPT can be disabled in the hypervisor via the 'kvm-intel.ept' parameter.
493
3.3. SMT and EPT supported and active
494
"""""""""""""""""""""""""""""""""""""
496
If SMT and EPT are supported and active then various degrees of
497
mitigations can be employed:
499
- L1D flushing on VMENTER:
501
L1D flushing on VMENTER is the minimal protection requirement, but it
502
is only potent in combination with other mitigation methods.
504
Conditional L1D flushing is the default behaviour and can be tuned. See
505
:ref:`mitigation_control_command_line` and :ref:`mitigation_control_kvm`.
507
- Guest confinement:
509
Confinement of guests to a single or a group of physical cores which
510
are not running any other processes, can reduce the attack surface
511
significantly, but interrupts, soft interrupts and kernel threads can
512
still expose valuable data to a potential attacker. See
513
:ref:`guest_confinement`.
515
- Interrupt isolation:
517
Isolating the guest CPUs from interrupts can reduce the attack surface
518
further, but still allows a malicious guest to explore a limited amount
519
of host physical memory. This can at least be used to gain knowledge
520
about the host address space layout. The interrupts which have a fixed
521
affinity to the CPUs which run the untrusted guests can depending on
522
the scenario still trigger soft interrupts and schedule kernel threads
523
which might expose valuable information. See
524
:ref:`interrupt_isolation`.
526
The above three mitigation methods combined can provide protection to a
527
certain degree, but the risk of the remaining attack surface has to be
528
carefully analyzed. For full protection the following methods are
529
available:
531
- Disabling SMT:
533
Disabling SMT and enforcing the L1D flushing provides the maximum
534
amount of protection. This mitigation is not depending on any of the
535
above mitigation methods.
537
SMT control and L1D flushing can be tuned by the command line
538
parameters 'nosmt', 'l1tf', 'kvm-intel.vmentry_l1d_flush' and at run
539
time with the matching sysfs control files. See :ref:`smt_control`,
540
:ref:`mitigation_control_command_line` and
541
:ref:`mitigation_control_kvm`.
543
- Disabling EPT:
545
Disabling EPT provides the maximum amount of protection as well. It is
546
not depending on any of the above mitigation methods. SMT can stay
547
enabled and L1D flushing is not required, but the performance impact is
548
significant.
550
EPT can be disabled in the hypervisor via the 'kvm-intel.ept'
551
parameter.
553
3.4. Nested virtual machines
554
""""""""""""""""""""""""""""
556
When nested virtualization is in use, three operating systems are involved:
557
the bare metal hypervisor, the nested hypervisor and the nested virtual
558
machine. VMENTER operations from the nested hypervisor into the nested
559
guest will always be processed by the bare metal hypervisor. If KVM is the
560
bare metal hypervisor it will:
562
- Flush the L1D cache on every switch from the nested hypervisor to the
563
nested virtual machine, so that the nested hypervisor's secrets are not
564
exposed to the nested virtual machine;
566
- Flush the L1D cache on every switch from the nested virtual machine to
567
the nested hypervisor; this is a complex operation, and flushing the L1D
568
cache avoids that the bare metal hypervisor's secrets are exposed to the
569
nested virtual machine;
571
- Instruct the nested hypervisor to not perform any L1D cache flush. This
572
is an optimization to avoid double L1D flushing.
575
.. _default_mitigations:
577
Default mitigations
578
-------------------
580
The kernel default mitigations for vulnerable processors are:
582
- PTE inversion to protect against malicious user space. This is done
583
unconditionally and cannot be controlled. The swap storage is limited
584
to ~16TB.
586
- L1D conditional flushing on VMENTER when EPT is enabled for
587
a guest.
589
The kernel does not by default enforce the disabling of SMT, which leaves
590
SMT systems vulnerable when running untrusted guests with EPT enabled.
592
The rationale for this choice is:
594
- Force disabling SMT can break existing setups, especially with
595
unattended updates.
597
- If regular users run untrusted guests on their machine, then L1TF is
598
just an add on to other malware which might be embedded in an untrusted
599
guest, e.g. spam-bots or attacks on the local network.
601
There is no technical way to prevent a user from running untrusted code
602
on their machines blindly.
604
- It's technically extremely unlikely and from today's knowledge even
605
impossible that L1TF can be exploited via the most popular attack
606
mechanisms like JavaScript because these mechanisms have no way to
607
control PTEs. If this would be possible and not other mitigation would
608
be possible, then the default might be different.
610
- The administrators of cloud and hosting setups have to carefully
611
analyze the risk for their scenarios and make the appropriate
612
mitigation choices, which might even vary across their deployed
613
machines and also result in other changes of their overall setup.
614
There is no way for the kernel to provide a sensible default for this
615
kind of scenarios.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
L1 Terminal Fault 개요
1-8L1 Terminal Fault(L1TF)는 access에 사용되는 virtual address를 제어하는 page table entry에서 Present bit가 지워졌거나 다른 reserved bit가 설정되어 있을 때, 권한 없는 코드가 Level 1 Data Cache에 있는 데이터에 speculative access할 수 있게 하는 hardware 취약점입니다.
영향받는 프로세서
9-31이 취약점은 광범위한 Intel 프로세서에 영향을 줍니다. 다음 프로세서에는 존재하지 않습니다.
- AMD, Centaur 및 기타 Intel 이외 vendor의 프로세서
- CPU family가 6보다 작은 오래된 processor model
- 일부 Intel ATOM(Cedarview, Cloverview, Lincroft, Penwell, Pineview, Silvermont, Airmont, Merrifield)
- Intel XEON PHI family
- `IA32_ARCH_CAPABILITIES` MSR에 `ARCH_CAP_RDCL_NO` bit가 설정된 Intel 프로세서. 이 bit가 설정된 CPU는 Meltdown의 영향도 받지 않습니다.
프로세서의 영향 여부는 sysfs의 L1TF vulnerability file에서 확인할 수 있습니다. 아래 L1TF system 정보 절을 참조하십시오.
관련 CVE
32-42| CVE | 문제 | 범위 |
|---|---|---|
| CVE-2018-3615 | L1 Terminal Fault | SGX related aspects |
| CVE-2018-3620 | L1 Terminal Fault | OS, SMM related aspects |
| CVE-2018-3646 | L1 Terminal Fault | Virtualization related aspects |
invalid PTE를 무시하는 speculative access
43-64instruction이 관련 page table entry(PTE)의 Present bit가 지워졌거나 다른 reserved bit가 설정된 virtual address에 access하면, speculative execution은 invalid PTE를 무시합니다. PTE의 address bit가 가리키는 page가 여전히 present이고 access 가능한 것처럼, 참조 데이터가 Level 1 Data Cache에 있으면 이를 load합니다.
이는 순수한 speculative 메커니즘이며 instruction이 retire될 때 결국 page fault를 일으킵니다. 그러나 데이터를 load해 다른 speculative instruction이 사용할 수 있게 하는 행위 자체가 Meltdown과 비슷한 side-channel attack 기회를 권한 없는 악성 코드에 제공합니다.
Meltdown이 userspace와 kernel space 사이의 보호를 깨는 데 비해 L1TF는 system의 어떤 physical memory address도 공격할 수 있고 모든 protection domain을 가로질러 동작합니다. SGX를 공격할 수 있으며, speculation이 extended page table(EPT) 보호를 우회하므로 virtual machine 내부에서도 동작합니다.
공격 시나리오 1: 악성 userspace
65-85Operating System은 non-present로 표시된 PTE의 address bit에 임의 정보를 저장합니다. 이 때문에 악성 userspace application이 해당 PTE가 해석되는 physical memory를 공격할 수 있습니다. 경우에 따라 userspace가 PTE address bit에 encode된 정보에 악의적으로 영향을 주어 공격을 더 결정적이고 실용적으로 만들 수 있습니다.
Linux 커널에는 이 attack vector를 위한 PTE inversion 완화가 있습니다. 항상 활성화되고 성능 영향은 없습니다. 커널은 present로 표시되지 않은 PTE의 address bit가 cache 가능한 physical memory space를 가리키지 않게 보장합니다.
최신 커널을 사용하는 system은 악성 userspace application의 공격으로부터 보호됩니다.
공격 시나리오 2: 악성 virtual-machine guest
86-118L1TF가 모든 domain protection을 깨므로 PTE를 직접 제어하는 악성 guest OS와, L1TF PTE inversion 완화가 없는 보호되지 않은 guest kernel 위의 악성 guest userspace application이 physical host memory를 공격할 수 있습니다.
virtualization 환경에서 특별히 중요한 요소는 symmetric multi threading(SMT), 즉 Intel의 HyperThreading입니다. 영향받는 프로세서의 Hyperthread는 L1 Data Cache(L1D)를 공유합니다. L1TF는 L1D에 있는 데이터만 공격하므로 한 Hyperthread의 악성 guest가 같은 physical core의 sibling Hyperthread에서 host OS, host userspace 또는 다른 guest가 L1D로 가져온 데이터를 공격할 수 있습니다.
프로세서가 Extended Page Tables를 지원하지 않는 경우에는 hypervisor가 유효한 shadow page table의 내용을 sanitize하지 않을 때만 공격할 수 있습니다.
이 attack vector를 완전히 막는 해법은 있지만 성능에 큰 영향을 줄 수 있어 Linux 커널에서는 기본으로 모두 활성화하지 않습니다. 배포 환경에 따라 선택할 수 있는 여러 메커니즘과 보호 범위·비용을 다음 절에서 설명하며, 기본 완화 선택의 근거는 문서 끝에 나옵니다.
L1TF sysfs system 정보
119-157Linux 커널은 system의 L1TF 취약 여부와 활성 완화를 다음 sysfs file로 제공합니다.
/sys/devices/system/cpu/vulnerabilities/l1tf| 기본 상태 | 의미 |
|---|---|
| Not affected | 프로세서가 취약하지 않습니다. |
| Mitigation: PTE Inversion | host protection이 활성화되어 있습니다. |
KVM/VMX가 활성화되어 있고 프로세서가 취약하면 다음 SMT 및 L1D flush 정보가 `Mitigation: PTE Inversion` 뒤에 붙습니다.
| SMT 상태 | 의미 |
|---|---|
| VMX: SMT vulnerable | SMT가 활성화되어 있습니다. |
| VMX: SMT disabled | SMT가 비활성화되어 있습니다. |
| L1D flush 상태 | 의미 |
|---|---|
| L1D vulnerable | L1D flushing이 비활성화되어 있습니다. |
| L1D conditional cache flushes | L1D flush가 조건부로 활성화되어 있습니다. |
| L1D cache flushes | L1D flush가 무조건 활성화되어 있습니다. |
최종 보호 수준은 이어지는 절에서 설명합니다.
host 완화
158-164커널은 host에서 실행되는 악성 userspace의 L1TF 공격으로부터 조건 없이 보호됩니다.
guest 완화 1: VMENTER의 L1D flush
165-214guest가 L1D에 있는 데이터를 공격하지 못하게 hypervisor는 guest에 들어가기 전에 L1D를 flush합니다.
L1D flush는 악성 guest가 access하면 안 되는 데이터뿐 아니라 guest 자신의 데이터도 evict합니다. processor가 guest 데이터를 다시 L1D로 가져와야 하므로 성능 비용이 생깁니다. guest의 VMEXIT/VMENTER 빈도와 계산 유형에 따라 1%에서 50%의 성능 저하가 관찰되었습니다. VMEXIT/VMENTER가 드물면 영향은 작습니다. Virtio와 posted interrupt 같은 메커니즘은 VMEXIT를 최소화하도록 설계되었지만 일부 구성과 application은 여전히 VMEXIT 비율이 높을 수 있습니다.
| mode | 동작 |
|---|---|
| conditional (cond) | VMEXIT 뒤 대응 VMENTER 전까지 감사된 code path만 실행된 경우 L1D flush를 생략합니다. 이 path는 secret을 노출하지 않지만 hypervisor address-space layout 정보는 누출할 수 있습니다. |
| unconditional (always) | 모든 VMENTER에서 L1D를 flush해 최대 보호를 제공합니다. conditional보다 overhead가 크며 workload와 VMEXIT 수에 따라 달라 정확히 일반화할 수 없습니다. |
일반적으로 VMENTER에서 L1D flush를 활성화하는 것이 권장됩니다. 영향받는 프로세서에서 커널 기본값은 conditional mode입니다.
L1D flush만으로는 SMT 문제를 막지 못합니다. sibling thread가 자신의 데이터를 L1D로 다시 가져오면 그 데이터가 다시 공격 가능해집니다. 관리자는 kernel command line과 sysfs control file로 L1D flush를 제어할 수 있습니다.
guest 완화 2: 전용 physical core에 VCPU 격리
215-247SMT 문제를 다루기 위해 guest 또는 관련 guest group을 하나 이상의 physical core에 affine하게 할 수 있습니다. exclusive cpuset을 사용해 다른 guest나 host task가 해당 core에서 실행되지 않도록 보장하는 것이 올바른 방법입니다.
한 physical core의 sibling SMT thread에서 단일 guest 또는 서로 관련된 guest만 실행하면 이들은 자신들의 memory와 제한된 host memory 부분만 공격할 수 있습니다.
한 sibling SMT thread가 host OS(hypervisor) context를, 다른 thread가 guest context를 실행하면 host memory를 공격할 수 있습니다. 노출 가치가 있는 정보의 양은 interrupt, soft interrupt, kernel thread 등 host OS가 실행하는 context에 따라 달라지며, 깊은 code 검토 없이 공격자에게 흥미롭지 않다고 단정할 수 없습니다.
guest를 고정 physical core 집합에 할당하면 scheduler의 load balancing 능력이 줄고 hosting 환경에 따라 CPU utilization이 나빠질 수 있습니다. 특정 환경에서는 SMT 비활성화가 대안입니다. 자세한 cpuset 정보는 다음 문서를 참조하십시오.
https://www.kernel.org/doc/Documentation/admin-guide/cgroup-v1/cpusets.rstguest 완화 3: interrupt affinity
248-274interrupt를 logical CPU에 affine하게 만들 수 있지만 local timer 같은 진정한 per-CPU interrupt가 있어 항상 가능한 것은 아닙니다. 또한 multi-queue device는 관리자가 affinity를 제어하지 못하는 상태에서 queue별 interrupt를 단일 CPU나 CPU group에 affine하게 할 수 있습니다.
affinity 제어가 가능한 interrupt를 신뢰할 수 없는 guest가 실행되는 CPU에서 다른 곳으로 옮기면 attack-vector 공간이 줄어듭니다. 다만 남은 interrupt가 공격자에게 유용한 데이터를 제공하는지는 system 구성과 workload에 따라 달라 일반화할 수 없습니다.
관리자는 `/proc/irq/$NR/smp_affinity[_list]` file로 interrupt affinity를 제어할 수 있습니다. 관련 문서는 다음과 같습니다.
https://www.kernel.org/doc/Documentation/core-api/irq/irq-affinity.rstguest 완화 4: SMT 제어
275-347L1TF의 SMT 문제를 막으려면 SMT를 완전히 비활성화해야 할 수 있습니다. 성능 영향은 hosting 환경과 workload에 따라 크며, guest를 전용 core에 격리하는 다른 완화의 비용과 함께 비교해야 합니다.
커널은 SMT 상태를 확인하고 제어하는 sysfs interface와 kernel command-line interface를 제공합니다.
| kernel option | 동작 |
|---|---|
| nosmt | boot 중 secondary CPU bring-up에 영향을 줍니다. 각 physical core에서 primary Hyperthread 하나만 활성화합니다. Intel Machine Check Exception 관련 설계 문제 때문에 non-primary sibling을 일부 bring up한 뒤 다시 내려야 합니다. sysfs에서 되돌릴 수 있습니다. |
| nosmt=force | `nosmt`와 같지만 sysfs에서 SMT 비활성화를 되돌릴 수 없습니다. |
/sys/devices/system/cpu/smt/control
/sys/devices/system/cpu/smt/active`/sys/devices/system/cpu/smt/control`은 SMT control 상태를 읽고 SMT를 끄거나 다시 켜는 기능을 제공합니다.
| control 상태 | 의미 |
|---|---|
| on | CPU가 SMT를 지원하고 활성화되어 있습니다. 모든 logical CPU를 제한 없이 online/offline할 수 있습니다. |
| off | CPU가 SMT를 지원하지만 비활성화되어 있습니다. primary SMT thread만 제한 없이 online/offline할 수 있고 non-primary sibling을 online하려는 시도는 거부됩니다. |
| forceoff | `off`와 같지만 상태를 제어할 수 없으며 control file write가 거부됩니다. |
| notsupported | 프로세서가 SMT를 지원하지 않아 L1TF의 SMT 영향도 받지 않습니다. control file write는 거부됩니다. |
control file에는 `on`, `off`, `forceoff`를 쓸 수 있습니다. `/sys/devices/system/cpu/smt/active`는 어느 physical core에서든 둘 이상의 sibling thread가 online인지, 즉 SMT가 활성 상태인지를 보고합니다. boot time에는 L1D flush 제어와 결합한 `l1tf` kernel parameter로도 SMT를 제어할 수 있습니다.
guest 완화 5: EPT 비활성화
348-363virtual machine에서 EPT를 비활성화하면 SMT가 활성화되어 있어도 L1TF를 완전히 완화할 수 있습니다. guest의 유효 page table을 hypervisor가 관리하고 sanitize하기 때문입니다. 다만 EPT 비활성화는 특히 Meltdown 완화 KPTI가 활성화된 경우 성능 영향이 큽니다.
hypervisor의 `kvm-intel.ept` parameter로 EPT를 비활성화할 수 있습니다. SMT 또는 EPT 비활성화의 성능 영향을 줄일 새 완화 메커니즘은 계속 연구·개발 중입니다.
l1tf= kernel command-line 제어
364-417boot time의 L1TF 완화는 `l1tf=` kernel command-line option으로 제어합니다.
| argument | 동작 |
|---|---|
| full | 사용 가능한 모든 L1TF 완화를 제공합니다. SMT를 끄고 hypervisor의 unconditional L1D flushing을 활성화합니다. boot 뒤 sysfs로 SMT와 L1D flush를 제어할 수 있으며, 잠재적으로 안전하지 않은 구성에서 첫 VM이 시작되면 hypervisor가 경고합니다. |
| full,force | `full`과 같지만 SMT 및 L1D flush runtime 제어를 비활성화합니다. `nosmt=force`를 암시하며 SMT sysfs 제어가 꺼집니다. |
| flush | SMT를 켜 둔 채 기본 hypervisor 완화인 conditional L1D flushing을 활성화합니다. sysfs runtime 제어는 가능하며 첫 VM 시작 시 안전하지 않은 구성이면 경고합니다. |
| flush,nosmt | SMT를 끄고 conditional L1D flushing을 활성화합니다. sysfs runtime 제어와 안전하지 않은 구성 경고는 유지됩니다. |
| flush,nowarn | `flush`와 같지만 안전하지 않은 구성에서 VM을 시작해도 hypervisor가 경고하지 않습니다. |
| off | hypervisor 완화와 경고를 끕니다. hypervisor와 bare metal 모두에서 swap size와 available RAM limit 제한도 제거합니다. |
기본값은 `flush`입니다. L1D flushing의 세부 동작은 앞의 VMENTER L1D flush 절을 참조하십시오.
KVM vmentry_l1d_flush 제어
418-449guest 진입 때 L1D cache를 flush하는 KVM 완화는 `kvm-intel.vmentry_l1d_flush=` option 또는 module parameter로 제어합니다.
| argument | 동작 |
|---|---|
| always | 모든 VMENTER에서 L1D cache를 flush합니다. |
| cond | VMEXIT와 VMENTER 사이 code가 공격자에게 흥미로운 host memory를 누출할 수 있을 때만 VMENTER에서 L1D를 flush합니다. host address-space layout을 알아낼 수 있는 memory는 여전히 누출될 수 있습니다. |
| never | 완화를 비활성화합니다. |
parameter는 kernel command line, module load parameter로 제공할 수 있고 다음 sysfs file에서 runtime에 바꿀 수 있습니다.
/sys/module/kvm_intel/parameters/vmentry_l1d_flush기본값은 `cond`입니다. command line에 `l1tf=full,force`가 있으면 `always`가 강제되고 module parameter는 무시되며 sysfs write도 거부됩니다.
완화 선택 지침과 nested virtualization
450-576| 환경 | 필수 조치 |
|---|---|
| virtualization을 사용하지 않음 | kernel이 system을 조건 없이 보호하므로 추가 조치가 필요 없습니다. |
| L1TF 완화가 보장된 신뢰할 수 있는 guest | system은 완전히 보호됩니다. VMENTER L1D flush overhead를 피하려면 관리자가 command line과 sysfs에서 flush를 끌 수 있습니다. |
| 신뢰할 수 없는 guest, SMT 미지원 또는 비활성화 | VMENTER L1D flushing만 강제하면 됩니다. conditional flush가 기본값입니다. |
| 신뢰할 수 없는 guest, EPT 미지원 또는 비활성화 | system이 완전히 보호됩니다. SMT를 켜 둘 수 있고 VMENTER L1D flush도 필요 없습니다. |
| 신뢰할 수 없는 guest, SMT와 EPT 모두 활성 | L1D flush가 최소 요구 사항이며 guest confinement와 interrupt isolation을 결합해 attack surface를 줄여야 합니다. 완전한 보호에는 SMT 또는 EPT 비활성화가 필요합니다. |
SMT와 EPT가 모두 활성인 경우 VMENTER의 L1D flushing만으로는 충분하지 않습니다. 전용 physical core에 guest를 격리하면 attack surface가 크게 줄지만 interrupt, soft interrupt, kernel thread가 여전히 데이터를 노출할 수 있습니다. guest CPU에서 interrupt를 격리하면 더 줄일 수 있지만 host address-space layout을 포함한 제한된 physical memory는 여전히 탐색될 수 있습니다.
위 세 방법을 함께 사용하면 일정 수준의 보호를 제공하지만 남은 위험을 신중히 분석해야 합니다. SMT를 끄고 L1D flushing을 강제하면 다른 완화에 의존하지 않는 최대 보호를 제공합니다. `nosmt`, `l1tf`, `kvm-intel.vmentry_l1d_flush`와 대응 sysfs file로 조정합니다. EPT를 끄는 방법도 최대 보호를 제공하며 SMT와 L1D flush에 의존하지 않지만 성능 영향이 큽니다.
nested virtualization에서는 bare-metal hypervisor, nested hypervisor, nested VM의 세 OS가 관여합니다. nested hypervisor에서 nested guest로의 VMENTER는 항상 bare-metal hypervisor가 처리합니다. bare-metal hypervisor가 KVM이면 다음을 수행합니다.
- nested hypervisor에서 nested VM으로 전환할 때마다 L1D를 flush해 nested hypervisor의 secret이 nested VM에 노출되지 않게 합니다.
- nested VM에서 nested hypervisor로 전환할 때마다 L1D를 flush합니다. 복잡한 전환 중 bare-metal hypervisor의 secret이 nested VM에 노출되는 것을 막습니다.
- 중복 L1D flush를 피하기 위해 nested hypervisor에는 L1D flush를 수행하지 말라고 지시합니다.
기본 완화와 선택 근거
577-615취약한 프로세서에 대한 커널 기본 완화는 다음과 같습니다.
- 악성 userspace를 막는 PTE inversion. 조건 없이 적용되며 제어할 수 없습니다. swap storage는 약 16TB로 제한됩니다.
- guest에 EPT가 활성화되어 있을 때 VMENTER에서 conditional L1D flushing.
커널은 기본적으로 SMT 비활성화를 강제하지 않습니다. 따라서 EPT가 활성화된 상태로 신뢰할 수 없는 guest를 실행하는 SMT system은 취약한 상태로 남습니다.
- SMT 강제 비활성화는 기존 환경, 특히 unattended update가 적용되는 환경을 망가뜨릴 수 있습니다.
- 일반 사용자가 신뢰할 수 없는 guest를 실행한다면 L1TF는 spam bot이나 local network 공격처럼 guest에 포함될 수 있는 다른 malware 문제에 추가되는 위험입니다. 사용자가 자신의 machine에서 신뢰할 수 없는 코드를 무심코 실행하는 것을 기술적으로 막을 방법은 없습니다.
- 현재 지식으로는 JavaScript 같은 널리 쓰이는 공격 메커니즘이 PTE를 제어할 수 없으므로 이를 통한 L1TF 악용은 극히 어렵고 사실상 불가능합니다. 이것이 가능해지고 다른 완화가 없다면 기본값이 달라질 수 있습니다.
- cloud 및 hosting 관리자는 환경별 위험을 신중히 분석해 적절한 완화를 선택해야 합니다. 선택은 배포 machine마다 다를 수 있고 전체 구성 변경으로 이어질 수 있으므로 커널이 합리적인 단일 기본값을 제공할 수 없습니다.
취약점과 공격 모델
l1tf.rst:1-118영향 CPU와 CVE, invalid PTE speculation, 악성 userspace 및 guest 공격을 설명합니다.