Q: What versions of the Linux kernel does grsecurity currently support, and for how long?

A: Grsecurity currently supports the 5.15 and 6.6 versions of the Linux kernel. Upstream, all of these kernel versions are LTS kernels. 5.15 will be supported through at least the end of 2025 and 6.6 at least through the end of 2026. Typically, we support each kernel for a period of at least 3 years, though this is often expanded to 4 years. When retiring a kernel and choosing a new one, we aim to provide a period of a few months overlap where three stable kernels are maintained at once, to allow a jump from the oldest version supported to the newest, if desired.

Q: What Linux distributions does grsecurity support?

A: Grsecurity supports all Linux distributions.

Q: What architectures does grsecurity support?

A: Grsecurity supports 32-bit and 64-bit ARM, 64-bit PowerPC, 32-bit and 64-bit x86, MIPS, and SPARC64. While around 80% of grsecurity is architecture-independent, some non-x86 architectures lack the full set of features grsecurity provides on x86, for various reasons. Please feel free to confirm the featureset with us for any architecture you plan to use. If a particular feature is missing, depending on the amount of R&D required, we can implement the feature as part of your pro support subscription or through a separate contract.

Q: What virtualized environments does grsecurity support?

A: Grsecurity supports all virtualization solutions (Xen, KVM, VMware, VirtualBox) and modes (HVM, PV, PVHVM, guest or host). Please note however that the individual choice of virtualization affects the functionality or presence of a few grsecurity features. Please feel free to ask us for any details about this.

Q: Is there any difference in the patches between the basic subscription and the subscription with pro support?

A: No, customers receive the same patches with the same features in either case.

Q: My current distribution's kernel version is (e.g. 3.10), does grsecurity support this version?

A: Grsecurity's kernels are based off upstream LTS kernels. Many Linux distributions pick an older version of Linux and only apply a small number of fixes to those kernels. It is very likely therefore that at least one of the kernel versions supported by grsecurity is newer than the version you are currently using. As backward compatibility with older userland is a goal of both ours and upstream, you will not experience problems in practice with using a version of Linux newer than that provided by your distribution. If you still have questions about potential compatibility issues, feel free to contact us, and we'll be happy to discuss them with you.

Q: How does grsecurity's backport process work?

A: Upstream LTS backporting generally involves applying fixes for issues that are specifically marked by the patch author for stable backporting. Through the course of our work, we've noticed at least two major flaws in the upstream backporting process: 1) Not every patch contributor provides the necessary "Fixes" or "Stable" tag necessary for a backport to be performed, and 2) even if a patch is selected for stable backporting, if it does not backport cleanly and no one upstream has performed the work to adapt the patch properly for the earlier kernel, it will not be backported. Likewise, there are a number of other rules with inconsistent application that may result in a patch not being backported despite being marked for such.

In contrast, our backporting process involves reviewing all upstream commits for security or reliability relevance, regardless of any specific markings. This involves an evaluation of the code to determine if the bug or vulnerability is present in the older kernel, as well as the additional work to adapt the fix properly. As a result of this effort, our maintained kernels contain several hundred more security and reliability fixes than their upstream counterparts. While we update to the latest relevant upstream LTS releases the same day in most cases, our independent backporting process happens in parallel every few days.

Q: Are grsecurity kernels suitable for systems with untrusted users?

A: Absolutely! While some upstream LTS kernel versions have recently been declared after Meltdown/Spectre to be unsuitable for untrusted users by their maintainer (see here), all currently-supported versions of grsecurity are recommended for such use. In fact, such uses are one of the main reasons to use grsecurity kernels. Due to our comprehensive backporting strategy, we know what security fixes upstream misses and are able to fill in the gaps. Our generic defensive measures provide a strong additional level of assurance for a wide variety of bug classes and exploitation vectors.

Q: What's the difference between PaX and grsecurity?

A: The PaX project began in 2000, a year before grsecurity. Early on we noticed we had similar goals of dealing with security in a more general way. While PaX focused purely on memory corruption-based bug classes, grsecurity initially built on work from Openwall and others and expanded its scope later. By providing access control and other defenses unrelated to memory corruption vulnerabilities, grsecurity aims to be as holistic an approach to security as can possibly be achieved in the kernel. While in the past it was possible to obtain PaX and grsecurity separately, using grsecurity (which includes all the work of PaX) has always been recommended. Grsecurity provides specific functionality that, while outside of the scope of the PaX project, is necessary for PaX's full security benefits to be realized. One example is the automatic brute-force prevention mechanisms for ASLR. Today, PaX is only available through the grsecurity patches provided to customers.

Q: What changes, if any, do I need to make to my userland binaries under grsecurity?

A: In general, the only changes that need to be made are to apply the proper PaX markings to binaries that need to make use of runtime-generated (e.g. JIT-compiled) code. For this purpose, we provide a free package called "paxctld" which automatically applies these markings on binaries requiring special settings. The markings are made via extended attributes, so the underlying binary contents are not modified at all. The package uses a simple human-readable configuration that makes adding additional exemptions easy. We are also happy to review and accept any additions for future versions of the package.

Q: What performance impact is there?

A: There is no single answer to this question, due to the variability in customers' workloads, system hardware, and enabled grsecurity features. All grsecurity features can be toggled on or off, many even at runtime. While enabling all features provides the greatest security benefit, certain features (e.g. memory sanitization on free) may only be considered a reasonable performance tradeoff under specific threat models. We specifically design features to operate as fast as possible on all ranges of hardware and baremetal/virtualized contexts. The implementation of UDEREF, for instance, can make use of both PCID and SMAP for improved performance. Though the performance overhead is very reasonable considering all the security functionality provided, if you have any performance concerns, please feel free to reach out to us. We care greatly about performance and will work with you to determine the best solution.

Q: Is grsecurity offered in a pre-compiled form?

A: At present, what we provide to customers is only what is available on the download page. This means that you will receive the source code of the grsecurity patches to apply to a Linux kernel. With a few simple commands, you can configure, compile, and install the grsecurity kernel on your systems, or even create kernel packages of your own.

Q: Can I still use a third-party patch/module (e.g. ZFS) with grsecurity?

A: In general, yes. For a third-party module to work with certain features of grsecurity, however, you will need to have the source code to that module. This is necessary so that our compiler plugins are able to instrument the code of the module properly and allow it to interact with the rest of the kernel. We officially support and provide patches for ZFS, NVIDIA, AUFS, and VirtualBox. If you'd like us to review a custom change outside of what we currently support, we'd be happy to do that as well. As RAP is a fine-grained CFI solution, it's often the case that out-of-tree modules need to be fixed for type correctness in order to perform properly with RAP enabled. We are happy to perform this kind of work as part of your grsecurity subscription.

Q: Why would I want to run a Linux kernel older than the latest version?

A: Contrary to widely repeated claims of the average Linux kernel vulnerability having a 5 year lifespan, it is in fact the latest kernels that contain the most vulnerabilities, as they introduce new and often untested code. The original claim came from this article. By depending on CVEs as the methodology of determining vulnerabilities, the results necessarily biased themselves to vulnerabilities found in older versions of Linux that distributions provide, as they are generally the only ones requesting CVEs. The minimal study plainly shows no vulnerabilities at all introduced for the newest three kernel versions, something now known to be false. The majority of vulnerabilities in Linux are fixed silently or without any CVE allocation, making CVE-based studies inherently flawed. Our experience with following all upstream commits, evaluating for potential security impact and relevance to other kernels, provides us with the knowledge that most vulnerabilities are introduced recently and fixed over a span of months (e.g. the waitid vulnerability). It takes time for new functionality or code undergoing churn to receive extensive testing (or for the constant flow of syzkaller reports to be acted on by the responsible parties), and it's for this reason that we have never recommended running the latest version of Linux available upstream.

Q: My Linux distribution has fixes available for vulnerabilities right after their announcement. Why use grsecurity?

A: The main benefits of grsecurity are: 1) not being vulnerable to several classes of vulnerabilities, and 2) making exploitation much more difficult and time-intensive in many cases, reducing the pool of potential attackers. The important timelines to consider are the time from vulnerability introduction to fix deployment, as well as public vulnerability discovery to fix deployment. Linux distributions are mainly involved in the cycle of fixing individual vulnerabilities. Many of these are reported from external sources through an embargo process that aims to keep the vulnerability info private for a period of time while fixes can be developed. This artificially eliminates much of the latter timeline, giving the false impression that a fix was developed immediately after an associated vulnerability was discovered. Most vulnerabilities however don't pass through this ideal process, and even the secretive embargoes tend to leak the longer they are imposed. It's for these common scenarios, as well as the former timeline, where grsecurity demonstrates its benefits.

With a sufficient exploit framework, certain vulnerabilities can be exploited in a matter of hours to days. Without more generalized defenses in place, it's simply not feasible to protect systems while depending on distribution updates alone. For vulnerabilities out of the public eye and not handled through an embargo process, the response times (if a fix is even created) of distros in general can be unacceptably long. It was recently publicized that one distro took 11 months to fix a Meltdown-level arbitrary read vulnerability in the kernel, three months after it was specifically called out as such on a public mailing list. Grsecurity was not affected by this vulnerability.

Q: Is grsecurity affected by the massive increase in CVEs assigned by the new Linux CNA?

A: No. Grsecurity already uses tested and fuzzed versions of upstream LTS kernels as its base. On top of this, we perform our own independent backports of security-relevant changes either missed entirely by the upstream process or for which backports have not been created due to code evolution.

Risk of exploitation cannot be determined by the mere presence or absence of a CVE identifier, especially when such identifiers are mostly being generated automatically without security expert review. Our security is based off the elimination of entire classes of vulnerabilities and exploitation techniques. Nevertheless, a vulnerability whose exploitation is prevented can often still have impacts on reliability, and some unique vulnerabilities (e.g. logic flaws) may not be preventable ahead of time, so we provide all fixes of the associated upstream LTS kernel as well as those identified through our independent process.

Via our Pro Support, we can provide customized guidance for your internal or product use, helping you limit your real risk through attack surface reduction and our proactive defenses.

Q: Does grsecurity have a free version for evaluation only?

A: Grsecurity fully complies with the license of the Linux kernel, the GPLv2. Since grsecurity is delivered as a source code patch, it is not possible under the terms of the GPL to offer a free version under an actual restriction that it be used only for evaluation purposes. Any customer receiving a grsecurity patch receives all the GPL-granted rights and responsibilities, including the right to redistribute patches in their possession or even to sell them to others.

Q: As an open source project, isn't grsecurity required to be available to the public at no charge?

A: This is an unfortunately common misconception. Since grsecurity is delivered only as a source code patch to customers, there are no additional obligations contained in the GPL requiring distribution from this website to other third parties. In fact, such demands run against the freedoms provided by the GPL: the freedom to charge for the service of distributing copies, as well as the freedom to choose whom to share, or not share, copies with. More information on these topics can be found via the following links from the Free Software Foundation, the creators of the GPL license:

https://www.gnu.org/licenses/gpl-faq.en.html#CanIDemandACopy
https://www.gnu.org/licenses/gpl-faq.en.html#DoesTheGPLAllowDownloadFee
https://www.gnu.org/licenses/gpl-faq.en.html#DoesTheGPLRequireAvailabilityToPublic

Beyond simply offering the grsecurity source code, Open Source Security, Inc. also provides continuous updates and maintenance, an extensive Customer Knowledge Base, and world-class support and custom development services. Customers of Open Source Security, Inc. are paying for the subscription service, not for a software license, just as one pays for a RHEL or Ubuntu subscription.