Linear Address Space Separation (LASS) mitigates a class of side-channel
attacks that rely on speculative access across the user/kernel boundary.
Enable LASS by default if the platform supports it. While at it, remove
the comment above the SMAP/SMEP/UMIP/LASS setup instead of updating it,
as the whole sequence is quite self-explanatory.
The legacy vsyscall page is mapped at 0xffffffffff60?000. Prior to LASS,
vsyscall page accesses would always generate a #PF. The kernel emulates
the accesses in the #PF handler and returns the appropriate values to
userspace.
With LASS, these accesses are intercepted before the paging structures
are traversed triggering a #GP instead of a #PF. To avoid breaking user
applications, equivalent emulation support is required in the #GP
handler. However, the #GP provides limited error information compared to
the #PF, making the emulation more complex.
For now, keep it simple and disable LASS if vsyscall emulation is
compiled in. This restricts LASS usability to newer environments where
legacy vsyscalls are absolutely not needed. In future, LASS support can
be expanded by enhancing the #GP handler.
Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
---
v11:
- Disable LASS if vsyscall emulation support is compiled in.
- Drop Rick's review tag because of the new changes.
v10
- No change.
---
arch/x86/kernel/cpu/common.c | 21 ++++++++++++++++++++-
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index c7d3512914ca..71e89859dfb4 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -401,6 +401,25 @@ static __always_inline void setup_umip(struct cpuinfo_x86 *c)
cr4_clear_bits(X86_CR4_UMIP);
}
+static __always_inline void setup_lass(struct cpuinfo_x86 *c)
+{
+ if (cpu_feature_enabled(X86_FEATURE_LASS)) {
+ /*
+ * Legacy vsyscall page access causes a #GP when LASS is
+ * active. However, vsyscall emulation isn't supported
+ * with #GP. To avoid breaking userspace, disable LASS
+ * if the emulation code is compiled in.
+ */
+ if (IS_ENABLED(CONFIG_X86_VSYSCALL_EMULATION)) {
+ pr_info_once("x86/cpu: Disabling LASS due to CONFIG_X86_VSYSCALL_EMULATION=y\n");
+ setup_clear_cpu_cap(X86_FEATURE_LASS);
+ return;
+ }
+
+ cr4_set_bits(X86_CR4_LASS);
+ }
+}
+
/* These bits should not change their value after CPU init is finished. */
static const unsigned long cr4_pinned_mask = X86_CR4_SMEP | X86_CR4_SMAP | X86_CR4_UMIP |
X86_CR4_FSGSBASE | X86_CR4_CET | X86_CR4_FRED;
@@ -2011,10 +2030,10 @@ static void identify_cpu(struct cpuinfo_x86 *c)
/* Disable the PN if appropriate */
squash_the_stupid_serial_number(c);
- /* Set up SMEP/SMAP/UMIP */
setup_smep(c);
setup_smap(c);
setup_umip(c);
+ setup_lass(c);
/* Enable FSGSBASE instructions if available. */
if (cpu_has(c, X86_FEATURE_FSGSBASE)) {
--
2.43.0On 10/29/25 14:03, Sohil Mehta wrote:
...
> +static __always_inline void setup_lass(struct cpuinfo_x86 *c)
> +{
> + if (cpu_feature_enabled(X86_FEATURE_LASS)) {
> + /*
> + * Legacy vsyscall page access causes a #GP when LASS is
> + * active. However, vsyscall emulation isn't supported
> + * with #GP. To avoid breaking userspace, disable LASS
> + * if the emulation code is compiled in.
> + */
> + if (IS_ENABLED(CONFIG_X86_VSYSCALL_EMULATION)) {
> + pr_info_once("x86/cpu: Disabling LASS due to CONFIG_X86_VSYSCALL_EMULATION=y\n");
> + setup_clear_cpu_cap(X86_FEATURE_LASS);
> + return;
> + }
> +
> + cr4_set_bits(X86_CR4_LASS);
> + }
> +}
This breaks two rules I have:
1. Indent as little as practical
2. Keep the main code flow at the lowest indentation level
IOW, this should be.
static __always_inline void setup_lass(struct cpuinfo_x86 *c)
{
if (!cpu_feature_enabled(X86_FEATURE_LASS))
return;
...
But I can fix that up when I apply this. I think it's mostly ready.
Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com>
On 10/31/2025 10:21 AM, Dave Hansen wrote: > > But I can fix that up when I apply this. I think it's mostly ready. > Thanks a lot for all the reviews. I'll try to get the EFI thing sorted. If we end up applying this revision, can you please remove the "default" from the patch title. Making LASS depend on CONFIG_X86_VSYSCALL_EMULATION makes it off by default.
On October 29, 2025 2:03:10 PM PDT, Sohil Mehta <sohil.mehta@intel.com> wrote:
>Linear Address Space Separation (LASS) mitigates a class of side-channel
>attacks that rely on speculative access across the user/kernel boundary.
>
>Enable LASS by default if the platform supports it. While at it, remove
>the comment above the SMAP/SMEP/UMIP/LASS setup instead of updating it,
>as the whole sequence is quite self-explanatory.
>
>The legacy vsyscall page is mapped at 0xffffffffff60?000. Prior to LASS,
>vsyscall page accesses would always generate a #PF. The kernel emulates
>the accesses in the #PF handler and returns the appropriate values to
>userspace.
>
>With LASS, these accesses are intercepted before the paging structures
>are traversed triggering a #GP instead of a #PF. To avoid breaking user
>applications, equivalent emulation support is required in the #GP
>handler. However, the #GP provides limited error information compared to
>the #PF, making the emulation more complex.
>
>For now, keep it simple and disable LASS if vsyscall emulation is
>compiled in. This restricts LASS usability to newer environments where
>legacy vsyscalls are absolutely not needed. In future, LASS support can
>be expanded by enhancing the #GP handler.
>
>Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
>---
>v11:
> - Disable LASS if vsyscall emulation support is compiled in.
> - Drop Rick's review tag because of the new changes.
>
>v10
> - No change.
>---
> arch/x86/kernel/cpu/common.c | 21 ++++++++++++++++++++-
> 1 file changed, 20 insertions(+), 1 deletion(-)
>
>diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
>index c7d3512914ca..71e89859dfb4 100644
>--- a/arch/x86/kernel/cpu/common.c
>+++ b/arch/x86/kernel/cpu/common.c
>@@ -401,6 +401,25 @@ static __always_inline void setup_umip(struct cpuinfo_x86 *c)
> cr4_clear_bits(X86_CR4_UMIP);
> }
>
>+static __always_inline void setup_lass(struct cpuinfo_x86 *c)
>+{
>+ if (cpu_feature_enabled(X86_FEATURE_LASS)) {
>+ /*
>+ * Legacy vsyscall page access causes a #GP when LASS is
>+ * active. However, vsyscall emulation isn't supported
>+ * with #GP. To avoid breaking userspace, disable LASS
>+ * if the emulation code is compiled in.
>+ */
>+ if (IS_ENABLED(CONFIG_X86_VSYSCALL_EMULATION)) {
>+ pr_info_once("x86/cpu: Disabling LASS due to CONFIG_X86_VSYSCALL_EMULATION=y\n");
>+ setup_clear_cpu_cap(X86_FEATURE_LASS);
>+ return;
>+ }
>+
>+ cr4_set_bits(X86_CR4_LASS);
>+ }
>+}
>+
> /* These bits should not change their value after CPU init is finished. */
> static const unsigned long cr4_pinned_mask = X86_CR4_SMEP | X86_CR4_SMAP | X86_CR4_UMIP |
> X86_CR4_FSGSBASE | X86_CR4_CET | X86_CR4_FRED;
>@@ -2011,10 +2030,10 @@ static void identify_cpu(struct cpuinfo_x86 *c)
> /* Disable the PN if appropriate */
> squash_the_stupid_serial_number(c);
>
>- /* Set up SMEP/SMAP/UMIP */
> setup_smep(c);
> setup_smap(c);
> setup_umip(c);
>+ setup_lass(c);
>
> /* Enable FSGSBASE instructions if available. */
> if (cpu_has(c, X86_FEATURE_FSGSBASE)) {
Legacy vsyscalls have been obsolete for how long now?
On 10/30/25 01:40, H. Peter Anvin wrote: > Legacy vsyscalls have been obsolete for how long now? I asked Sohil to start throwing out all the non-essential bits from this series. My thought was that we could get mainline so that LASS itself could be enabled, even if it was in a somewhat weird config that a distro would probably never do. After that is merged, we can circle back and decide what to do with the remaining bits like CR pinning and vsyscall emulation. I don't think any of those bits will change the basic desire to have LASS support in the kernel. Does that sound like a sane approach to everyone?
On 2025-10-30 09:27, Dave Hansen wrote: > On 10/30/25 01:40, H. Peter Anvin wrote: >> Legacy vsyscalls have been obsolete for how long now? > > I asked Sohil to start throwing out all the non-essential bits from this > series. My thought was that we could get mainline so that LASS itself > could be enabled, even if it was in a somewhat weird config that a > distro would probably never do. > > After that is merged, we can circle back and decide what to do with the > remaining bits like CR pinning and vsyscall emulation. I don't think any > of those bits will change the basic desire to have LASS support in the > kernel. > > Does that sound like a sane approach to everyone? XONLY vsyscall emulation should be trivial, though (just look for the magic RIP values, just like the page fault code does now, too.) The FULL emulation mode is completely irrelevant these days, so I don't think it matters at all. EFI handling is similarly straightforward: just disable CR4.LASS right before calling EFI, and enable it on return. As long as we are *already* in the efi_mm context, it is perfectly safe to disable CR4.LASS, because there *is no user memory mapped at that point*. These two things should only be a few lines of code each, and I don't see any reason to further elaborate them at this time (to handle FULL emulation, or to take a LASS trap inside EFI to write a shame-the-vendor message; if we wanted to do that, it would be better to make that independent of LASS and empty out efi_mm entirely. Am I missing something? -hpa
On 11/7/2025 12:01 AM, H. Peter Anvin wrote: >> I asked Sohil to start throwing out all the non-essential bits from this >> series. My thought was that we could get mainline so that LASS itself >> could be enabled, even if it was in a somewhat weird config that a >> distro would probably never do. >> >> After that is merged, we can circle back and decide what to do with the >> remaining bits like CR pinning and vsyscall emulation. I don't think any >> of those bits will change the basic desire to have LASS support in the >> kernel. >> >> Does that sound like a sane approach to everyone? > > XONLY vsyscall emulation should be trivial, though (just look for the magic > RIP values, just like the page fault code does now, too.) The FULL emulation > mode is completely irrelevant these days, so I don't think it matters at all. > Yes, the actual change is quite simple. But along with minor refactoring and updates to code comments and documentation, it ends up being a set of 3 to 4 small patches. > EFI handling is similarly straightforward: just disable CR4.LASS right before > calling EFI, and enable it on return. As long as we are *already* in the > efi_mm context, it is perfectly safe to disable CR4.LASS, because there *is no > user memory mapped at that point*. > At a minimum, We need to defer the initial LASS enabling until we are truly done with the boot services memory, i.e. efi_enter_virtual_mode() has completed (including efi_free_boot_services()). Also, there is preference for deferring LASS enabling until userspace comes up. Again, all of that should be simple enough but ends up adding to the patch count (touching 20 now). It was getting difficult to get the reviews/acks from experts in all the impacted areas. Dave's suggestion of splitting the series makes it easier to merge the base set and get focussed reviews on the missing features. My plan is to promptly follow up with the EFI and Vsyscall support to make LASS enabled by default. > These two things should only be a few lines of code each, and I don't see any > reason to further elaborate them at this time (to handle FULL emulation, or to Yes, there is absolutely no need to support the full vsyscall emulation. > take a LASS trap inside EFI to write a shame-the-vendor message; if we wanted > to do that, it would be better to make that independent of LASS and empty out > efi_mm entirely. > This seems to be the takeaway of PeterZ's interaction with Ard. Though, I agree, warning about misbehaving firmware should probably be done separately and independent of LASS. I'll send out another revision of this series without EFI next week, and follow up with support for EFI and vsyscall soon after.
On Thu, Oct 30, 2025, at 1:40 AM, H. Peter Anvin wrote:
> On October 29, 2025 2:03:10 PM PDT, Sohil Mehta <sohil.mehta@intel.com> wrote:
>>Linear Address Space Separation (LASS) mitigates a class of side-channel
>>attacks that rely on speculative access across the user/kernel boundary.
>>
>>Enable LASS by default if the platform supports it. While at it, remove
>>the comment above the SMAP/SMEP/UMIP/LASS setup instead of updating it,
>>as the whole sequence is quite self-explanatory.
>>
>>The legacy vsyscall page is mapped at 0xffffffffff60?000. Prior to LASS,
>>vsyscall page accesses would always generate a #PF. The kernel emulates
>>the accesses in the #PF handler and returns the appropriate values to
>>userspace.
>>
>>With LASS, these accesses are intercepted before the paging structures
>>are traversed triggering a #GP instead of a #PF. To avoid breaking user
>>applications, equivalent emulation support is required in the #GP
>>handler. However, the #GP provides limited error information compared to
>>the #PF, making the emulation more complex.
>>
>>For now, keep it simple and disable LASS if vsyscall emulation is
>>compiled in. This restricts LASS usability to newer environments where
>>legacy vsyscalls are absolutely not needed. In future, LASS support can
>>be expanded by enhancing the #GP handler.
>>
>>Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
>>---
>>v11:
>> - Disable LASS if vsyscall emulation support is compiled in.
>> - Drop Rick's review tag because of the new changes.
>>
>>v10
>> - No change.
>>---
>> arch/x86/kernel/cpu/common.c | 21 ++++++++++++++++++++-
>> 1 file changed, 20 insertions(+), 1 deletion(-)
>>
>>diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
>>index c7d3512914ca..71e89859dfb4 100644
>>--- a/arch/x86/kernel/cpu/common.c
>>+++ b/arch/x86/kernel/cpu/common.c
>>@@ -401,6 +401,25 @@ static __always_inline void setup_umip(struct cpuinfo_x86 *c)
>> cr4_clear_bits(X86_CR4_UMIP);
>> }
>>
>>+static __always_inline void setup_lass(struct cpuinfo_x86 *c)
>>+{
>>+ if (cpu_feature_enabled(X86_FEATURE_LASS)) {
>>+ /*
>>+ * Legacy vsyscall page access causes a #GP when LASS is
>>+ * active. However, vsyscall emulation isn't supported
>>+ * with #GP. To avoid breaking userspace, disable LASS
>>+ * if the emulation code is compiled in.
>>+ */
>>+ if (IS_ENABLED(CONFIG_X86_VSYSCALL_EMULATION)) {
>>+ pr_info_once("x86/cpu: Disabling LASS due to CONFIG_X86_VSYSCALL_EMULATION=y\n");
>>+ setup_clear_cpu_cap(X86_FEATURE_LASS);
>>+ return;
>>+ }
>>+
>>+ cr4_set_bits(X86_CR4_LASS);
>>+ }
>>+}
>>+
>> /* These bits should not change their value after CPU init is finished. */
>> static const unsigned long cr4_pinned_mask = X86_CR4_SMEP | X86_CR4_SMAP | X86_CR4_UMIP |
>> X86_CR4_FSGSBASE | X86_CR4_CET | X86_CR4_FRED;
>>@@ -2011,10 +2030,10 @@ static void identify_cpu(struct cpuinfo_x86 *c)
>> /* Disable the PN if appropriate */
>> squash_the_stupid_serial_number(c);
>>
>>- /* Set up SMEP/SMAP/UMIP */
>> setup_smep(c);
>> setup_smap(c);
>> setup_umip(c);
>>+ setup_lass(c);
>>
>> /* Enable FSGSBASE instructions if available. */
>> if (cpu_has(c, X86_FEATURE_FSGSBASE)) {
>
> Legacy vsyscalls have been obsolete for how long now?
A looooong time.
I would suggest defaulting LASS to on and *maybe* decoding just enough to log, once per boot, that a legacy vsyscall may have been attempted. It’s too bad that #GP doesn’t report the faulting address.
—Andy
On 10/30/2025 8:45 AM, Andy Lutomirski wrote: > On Thu, Oct 30, 2025, at 1:40 AM, H. Peter Anvin wrote: >> Legacy vsyscalls have been obsolete for how long now? > > A looooong time. > > I would suggest defaulting LASS to on and *maybe* decoding just enough to log, once per boot, that a legacy vsyscall may have been attempted. It’s too bad that #GP doesn’t report the faulting address. > Unfortunately, CONFIG_X86_VSYSCALL_EMULATION defaults to y. Also, the default Vsyscall mode is XONLY. So even if vsyscalls are deprecated, there is a non-zero possibility someone would complain about it. My primary goal here is to get the base LASS series merged (soonish) with the simplest possible option. I am planning to follow-up immediately with a vsyscall specific series that relaxes *most* restrictions. IIUC, supporting XONLY mode with LASS probably does not need complicated decoding because the vsyscall address is available in the faulting RIP. The spec says: "LASS for instruction fetches applies when the linear address in RIP is used to load an instruction from memory. Unlike canonicality checking (see Section 4.5.2), LASS does not apply to branch instructions that load RIP. A branch instruction can load RIP with an address that would violate LASS. Only when the address is used to fetch an instruction will a LASS violation occur, generating a #GP. (The return instruction pointer of the #GP handler is the address that incurred the LASS violation.)" I attempted to do that in the last revision here: https://lore.kernel.org/lkml/20251007065119.148605-9-sohil.mehta@intel.com/ https://lore.kernel.org/lkml/20251007065119.148605-11-sohil.mehta@intel.com/ On the other hand, supporting EMULATE mode during a #GP is a bit tricky, which isn't worth the effort.
On Thu, 30 Oct 2025 09:44:02 -0700 Sohil Mehta <sohil.mehta@intel.com> wrote: > On 10/30/2025 8:45 AM, Andy Lutomirski wrote: > > On Thu, Oct 30, 2025, at 1:40 AM, H. Peter Anvin wrote: > >> Legacy vsyscalls have been obsolete for how long now? > > > > A looooong time. > > > > I would suggest defaulting LASS to on and *maybe* decoding just enough to log, once per boot, that a legacy vsyscall may have been attempted. It’s too bad that #GP doesn’t report the faulting address. > > > > Unfortunately, CONFIG_X86_VSYSCALL_EMULATION defaults to y. Also, the > default Vsyscall mode is XONLY. So even if vsyscalls are deprecated, > there is a non-zero possibility someone would complain about it. Presumably a command line parameter could be used to disable LASS in order to enable vsyscall emulation? That might let LASS be enabled by default. David
On 10/30/25 14:13, David Laight wrote: >> Unfortunately, CONFIG_X86_VSYSCALL_EMULATION defaults to y. Also, the >> default Vsyscall mode is XONLY. So even if vsyscalls are deprecated, >> there is a non-zero possibility someone would complain about it. > Presumably a command line parameter could be used to disable LASS > in order to enable vsyscall emulation? > > That might let LASS be enabled by default. Sure... There are a million ways to skin this cat. That's the problem. The compile switch is the smallest amount of code with the fewest implications to ABI or documentation that we can muster. All I'm saying is we should _start_ here, not _end_ here. If anyone agrees with that approach, acks would be appreciated.
On October 30, 2025 2:13:18 PM PDT, David Laight <david.laight.linux@gmail.com> wrote: >On Thu, 30 Oct 2025 09:44:02 -0700 >Sohil Mehta <sohil.mehta@intel.com> wrote: > >> On 10/30/2025 8:45 AM, Andy Lutomirski wrote: >> > On Thu, Oct 30, 2025, at 1:40 AM, H. Peter Anvin wrote: >> >> Legacy vsyscalls have been obsolete for how long now? >> > >> > A looooong time. >> > >> > I would suggest defaulting LASS to on and *maybe* decoding just enough to log, once per boot, that a legacy vsyscall may have been attempted. It’s too bad that #GP doesn’t report the faulting address. >> > >> >> Unfortunately, CONFIG_X86_VSYSCALL_EMULATION defaults to y. Also, the >> default Vsyscall mode is XONLY. So even if vsyscalls are deprecated, >> there is a non-zero possibility someone would complain about it. > >Presumably a command line parameter could be used to disable LASS >in order to enable vsyscall emulation? > >That might let LASS be enabled by default. > > David > So I talked with Sohil about this earlier today, and there was a bit of a miscommunication — XONLY mode is just fine. It is read emulation mode that has problems.
On Thu, Oct 30, 2025, at 9:44 AM, Sohil Mehta wrote: > On 10/30/2025 8:45 AM, Andy Lutomirski wrote: >> On Thu, Oct 30, 2025, at 1:40 AM, H. Peter Anvin wrote: >>> Legacy vsyscalls have been obsolete for how long now? >> >> A looooong time. >> >> I would suggest defaulting LASS to on and *maybe* decoding just enough to log, once per boot, that a legacy vsyscall may have been attempted. It’s too bad that #GP doesn’t report the faulting address. >> > > Unfortunately, CONFIG_X86_VSYSCALL_EMULATION defaults to y. Also, the > default Vsyscall mode is XONLY. So even if vsyscalls are deprecated, > there is a non-zero possibility someone would complain about it. > > My primary goal here is to get the base LASS series merged (soonish) > with the simplest possible option. > > I am planning to follow-up immediately with a vsyscall specific series > that relaxes *most* restrictions. > > IIUC, supporting XONLY mode with LASS probably does not need complicated > decoding because the vsyscall address is available in the faulting RIP. > > The spec says: > "LASS for instruction fetches applies when the linear address in RIP is > used to load an instruction from memory. Unlike canonicality checking > (see Section 4.5.2), LASS does not apply to branch instructions that > load RIP. A branch instruction can load RIP with an address that would > violate LASS. Only when the address is used to fetch an instruction will > a LASS violation occur, generating a #GP. (The return instruction > pointer of the #GP handler is the address that incurred the LASS > violation.)" > > I attempted to do that in the last revision here: > https://lore.kernel.org/lkml/20251007065119.148605-9-sohil.mehta@intel.com/ > https://lore.kernel.org/lkml/20251007065119.148605-11-sohil.mehta@intel.com/ > > On the other hand, supporting EMULATE mode during a #GP is a bit tricky, > which isn't worth the effort. I would say it's definitely worth the effort, but it probably does make sense to get the rest of the series in a mergeable condition such that it only works with vsyscall=none.
On 10/30/2025 9:53 AM, Andy Lutomirski wrote: >> On the other hand, supporting EMULATE mode during a #GP is a bit tricky, >> which isn't worth the effort. > > I would say it's definitely worth the effort, but it probably does make sense to get the rest of the series in a mergeable condition such that it only works with vsyscall=none. I meant the full emulation mode where the Vsyscall page is readable. It is only available via vsyscall=emulate. No one should be using that one, right? I thought you and Linus agreed on removing EMULATE mode completely: https://lore.kernel.org/all/CALCETrXHJ7837+cmahg-wjR3iRHbDJ6JtVGaoDFC4dx-L8r8OA@mail.gmail.com/ I agree that it would be worthwhile (and relatively easy) to support the execute (XONLY) mode (that only does instruction fetches). That is what the separate vsyscall series would do once the LASS base is in.
On Thu, Oct 30, 2025, at 10:24 AM, Sohil Mehta wrote: > On 10/30/2025 9:53 AM, Andy Lutomirski wrote: > >>> On the other hand, supporting EMULATE mode during a #GP is a bit tricky, >>> which isn't worth the effort. >> >> I would say it's definitely worth the effort, but it probably does make sense to get the rest of the series in a mergeable condition such that it only works with vsyscall=none. > > I meant the full emulation mode where the Vsyscall page is readable. It > is only available via vsyscall=emulate. No one should be using that one, > right? > > I thought you and Linus agreed on removing EMULATE mode completely: > https://lore.kernel.org/all/CALCETrXHJ7837+cmahg-wjR3iRHbDJ6JtVGaoDFC4dx-L8r8OA@mail.gmail.com/ > > I agree that it would be worthwhile (and relatively easy) to support the > execute (XONLY) mode (that only does instruction fetches). That is what > the separate vsyscall series would do once the LASS base is in. Ah, I misunderstood you. I agree.
© 2016 - 2025 Red Hat, Inc.