* Re: [PATCH] Documentation: DMA-API: fix a function name of max_mapping_size
From: Christoph Hellwig @ 2019-06-07 8:34 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: Christoph Hellwig, corbet@lwn.net, jroedel@suse.de,
m.szyprowski@samsung.com, linux-doc@vger.kernel.org,
iommu@lists.linux-foundation.org
In-Reply-To: <TYAPR01MB3102C6CCC204DAAA6570FD25D8100@TYAPR01MB3102.jpnprd01.prod.outlook.com>
On Fri, Jun 07, 2019 at 08:19:08AM +0000, Yoshihiro Shimoda wrote:
> Hi Christoph,
>
> > From: Christoph Hellwig, Sent: Friday, June 7, 2019 5:08 PM
> >
> > Looks good. And it seems like you've also found the solution to
> > your usb storage problem, but I'm going to post the variant I just
> > hacked up nevertheless.
>
> Thank you for your reply! I think this API is related to my problem,
> but I don't have any actual solution (a patch) for now. So, I'll wait
> for your patch!
Turns out it isn't as simple as I thought, as there doesn't seem to
be an easy way to get to the struct device used for DMA mapping
from USB drivers. I'll need to think a bit more how to handle that
best.
^ permalink raw reply
* Re: [PATCH v3 2/3] x86: Use static_cpu_has in uaccess region to avoid instrumentation
From: Marco Elver @ 2019-06-07 9:43 UTC (permalink / raw)
To: Peter Zijlstra, Andrey Ryabinin, Dmitry Vyukov,
Alexander Potapenko, Andrey Konovalov, Mark Rutland,
H. Peter Anvin
Cc: Jonathan Corbet, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
the arch/x86 maintainers, Arnd Bergmann, Josh Poimboeuf,
open list:DOCUMENTATION, LKML, linux-arch, kasan-dev
In-Reply-To: <20190531150828.157832-3-elver@google.com>
Gentle ping. I would appreciate quick feedback if this approach is reasonable.
Peter: since you suggested that we should not change objtool, did you
have a particular approach in mind that is maybe different from v2 and
v3? Or is this what you were thinking of?
Many thanks!
On Fri, 31 May 2019 at 17:11, Marco Elver <elver@google.com> wrote:
>
> This patch is a pre-requisite for enabling KASAN bitops instrumentation;
> using static_cpu_has instead of boot_cpu_has avoids instrumentation of
> test_bit inside the uaccess region. With instrumentation, the KASAN
> check would otherwise be flagged by objtool.
>
> For consistency, kernel/signal.c was changed to mirror this change,
> however, is never instrumented with KASAN (currently unsupported under
> x86 32bit).
>
> Signed-off-by: Marco Elver <elver@google.com>
> Suggested-by: H. Peter Anvin <hpa@zytor.com>
> ---
> Changes in v3:
> * Use static_cpu_has instead of moving boot_cpu_has outside uaccess
> region.
>
> Changes in v2:
> * Replaces patch: 'tools/objtool: add kasan_check_* to uaccess
> whitelist'
> ---
> arch/x86/ia32/ia32_signal.c | 2 +-
> arch/x86/kernel/signal.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/ia32/ia32_signal.c b/arch/x86/ia32/ia32_signal.c
> index 629d1ee05599..1cee10091b9f 100644
> --- a/arch/x86/ia32/ia32_signal.c
> +++ b/arch/x86/ia32/ia32_signal.c
> @@ -358,7 +358,7 @@ int ia32_setup_rt_frame(int sig, struct ksignal *ksig,
> put_user_ex(ptr_to_compat(&frame->uc), &frame->puc);
>
> /* Create the ucontext. */
> - if (boot_cpu_has(X86_FEATURE_XSAVE))
> + if (static_cpu_has(X86_FEATURE_XSAVE))
> put_user_ex(UC_FP_XSTATE, &frame->uc.uc_flags);
> else
> put_user_ex(0, &frame->uc.uc_flags);
> diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
> index 364813cea647..52eb1d551aed 100644
> --- a/arch/x86/kernel/signal.c
> +++ b/arch/x86/kernel/signal.c
> @@ -391,7 +391,7 @@ static int __setup_rt_frame(int sig, struct ksignal *ksig,
> put_user_ex(&frame->uc, &frame->puc);
>
> /* Create the ucontext. */
> - if (boot_cpu_has(X86_FEATURE_XSAVE))
> + if (static_cpu_has(X86_FEATURE_XSAVE))
> put_user_ex(UC_FP_XSTATE, &frame->uc.uc_flags);
> else
> put_user_ex(0, &frame->uc.uc_flags);
> --
> 2.22.0.rc1.257.g3120a18244-goog
>
^ permalink raw reply
* [RFC] NUMA Description Under ACPI 6.3 White Paper (v0.93)
From: Jonathan Cameron @ 2019-06-07 9:52 UTC (permalink / raw)
To: linux-acpi, linux-mm, linux-kernel, linux-doc, linuxarm
Hi all,
This is a request for comment / review on a white paper, intended to
provide an example lead guide on how to describe NUMA systems in ACPI 6.3.
https://github.com/hisilicon/acpi-numa-whitepaper
https://github.com/hisilicon/acpi-numa-whitepaper/releases/download/v0.93/NUMA_Description_Under_ACPI_6.3_v0.93.pdf
It was prepared in conjunction with the Heterogeneous Memory Sub Team (HMST) of
the UEFI forum which has a mix of firmware and OS people (Linux and others).
The original motivation for this was that we were writing some docs for a
more specific project (to appear shortly) and realized that only reason
some sections were necessary was because we couldn't find anything
bridging the gap between the ACPI specification and docs like those in
the kernel tree. Hence this document targeting that hole which is hopefully
of more general use.
Exactly how this will be officially 'released' is yet to be resolved, but
however that happens we will be maintaining a public source repository,
hopefully allowing this to be a living document, tracking future specs
and also being updated to account for how OS usage of the provided information
changes.
The document is under Creative Commons Attribution 4.0 International License.
It is a Sphinx document. Only output to pdf has been tested and
the build scripts are a bit of a mess.
Thanks to all those who have already given feedback on earlier drafts!
Additional thanks to the members of HMST for some very interesting discussions,
clarifying both my understanding and highlighting areas to focus on in this
guide.
I'm looking for all types of feedback including suggestions for
missing content (as a patch is ideal of course - I'm more than happy
to have some coauthors on this).
Jonathan
p.s. Please share with anyone you think may be interested!
^ permalink raw reply
* [PATCH trivial] Documentation: tee: Grammar s/the its/its/
From: Geert Uytterhoeven @ 2019-06-07 11:07 UTC (permalink / raw)
To: Jens Wiklander, Jonathan Corbet, Jiri Kosina
Cc: linux-doc, linux-kernel, Geert Uytterhoeven
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Documentation/tee.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/tee.txt b/Documentation/tee.txt
index 56ea85ffebf24545..afacdf2fd1de5455 100644
--- a/Documentation/tee.txt
+++ b/Documentation/tee.txt
@@ -32,7 +32,7 @@ User space (the client) connects to the driver by opening /dev/tee[0-9]* or
memory.
- TEE_IOC_VERSION lets user space know which TEE this driver handles and
- the its capabilities.
+ its capabilities.
- TEE_IOC_OPEN_SESSION opens a new session to a Trusted Application.
--
2.17.1
^ permalink raw reply related
* [PATCH trivial] Documentation: net: dsa: Grammar s/the its/its/
From: Geert Uytterhoeven @ 2019-06-07 11:08 UTC (permalink / raw)
To: David S . Miller, Jonathan Corbet, Jiri Kosina
Cc: netdev, linux-doc, linux-kernel, Geert Uytterhoeven
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Documentation/networking/dsa/dsa.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst
index ca87068b9ab904a9..563d56c6a25c924e 100644
--- a/Documentation/networking/dsa/dsa.rst
+++ b/Documentation/networking/dsa/dsa.rst
@@ -531,7 +531,7 @@ Bridge VLAN filtering
a software implementation.
.. note:: VLAN ID 0 corresponds to the port private database, which, in the context
- of DSA, would be the its port-based VLAN, used by the associated bridge device.
+ of DSA, would be its port-based VLAN, used by the associated bridge device.
- ``port_fdb_del``: bridge layer function invoked when the bridge wants to remove a
Forwarding Database entry, the switch hardware should be programmed to delete
@@ -554,7 +554,7 @@ Bridge VLAN filtering
associated with this VLAN ID.
.. note:: VLAN ID 0 corresponds to the port private database, which, in the context
- of DSA, would be the its port-based VLAN, used by the associated bridge device.
+ of DSA, would be its port-based VLAN, used by the associated bridge device.
- ``port_mdb_del``: bridge layer function invoked when the bridge wants to remove a
multicast database entry, the switch hardware should be programmed to delete
--
2.17.1
^ permalink raw reply related
* [PATCH trivial] KVM: arm/arm64: Always capitalize ITS
From: Geert Uytterhoeven @ 2019-06-07 11:29 UTC (permalink / raw)
To: Paolo Bonzini, Radim Krčmář, Jonathan Corbet,
Jiri Kosina
Cc: kvm, linux-doc, linux-kernel, Geert Uytterhoeven
All but one reference is capitalized. Fix the remaining one.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Documentation/virtual/kvm/devices/arm-vgic-its.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/virtual/kvm/devices/arm-vgic-its.txt b/Documentation/virtual/kvm/devices/arm-vgic-its.txt
index 4f0c9fc403656d29..eeaa95b893a89b7a 100644
--- a/Documentation/virtual/kvm/devices/arm-vgic-its.txt
+++ b/Documentation/virtual/kvm/devices/arm-vgic-its.txt
@@ -103,7 +103,7 @@ Groups:
The following ordering must be followed when restoring the GIC and the ITS:
a) restore all guest memory and create vcpus
b) restore all redistributors
-c) provide the its base address
+c) provide the ITS base address
(KVM_DEV_ARM_VGIC_GRP_ADDR)
d) restore the ITS in the following order:
1. Restore GITS_CBASER
--
2.17.1
^ permalink raw reply related
* RE: [PATCH] Documentation: DMA-API: fix a function name of max_mapping_size
From: Yoshihiro Shimoda @ 2019-06-07 12:04 UTC (permalink / raw)
To: Christoph Hellwig
Cc: corbet@lwn.net, jroedel@suse.de, m.szyprowski@samsung.com,
linux-doc@vger.kernel.org, iommu@lists.linux-foundation.org
In-Reply-To: <20190607083447.GA10860@lst.de>
Hi Christoph,
> From: Christoph Hellwig, Sent: Friday, June 7, 2019 5:35 PM
>
> On Fri, Jun 07, 2019 at 08:19:08AM +0000, Yoshihiro Shimoda wrote:
> > Hi Christoph,
> >
> > > From: Christoph Hellwig, Sent: Friday, June 7, 2019 5:08 PM
> > >
> > > Looks good. And it seems like you've also found the solution to
> > > your usb storage problem, but I'm going to post the variant I just
> > > hacked up nevertheless.
> >
> > Thank you for your reply! I think this API is related to my problem,
> > but I don't have any actual solution (a patch) for now. So, I'll wait
> > for your patch!
>
> Turns out it isn't as simple as I thought, as there doesn't seem to
> be an easy way to get to the struct device used for DMA mapping
> from USB drivers. I'll need to think a bit more how to handle that
> best.
Thank you for your reply. I sent an email on the original report as below.
https://marc.info/?l=linux-block&m=155990883224615&w=2
Best regards,
Yoshihiro Shimoda
^ permalink raw reply
* Re: [PATCH trivial] Documentation: net: dsa: Grammar s/the its/its/
From: Andrew Lunn @ 2019-06-07 13:08 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: David S . Miller, Jonathan Corbet, Jiri Kosina, netdev, linux-doc,
linux-kernel
In-Reply-To: <20190607110842.12876-1-geert+renesas@glider.be>
On Fri, Jun 07, 2019 at 01:08:42PM +0200, Geert Uytterhoeven wrote:
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH 2/3] treewide: trivial: fix s/poped/popped/ typo
From: Masami Hiramatsu @ 2019-06-07 14:22 UTC (permalink / raw)
To: George G. Davis
Cc: Jonathan Corbet, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
H. Peter Anvin, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Jiri Kosina, Steven Rostedt, Andi Kleen, Jann Horn, Nadav Amit,
open list:DOCUMENTATION, open list
In-Reply-To: <1559766612-12178-2-git-send-email-george_davis@mentor.com>
On Wed, 5 Jun 2019 16:30:10 -0400
"George G. Davis" <george_davis@mentor.com> wrote:
> Fix a couple of s/poped/popped/ typos.
>
> Cc: Jiri Kosina <trivial@kernel.org>
> Signed-off-by: George G. Davis <george_davis@mentor.com>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Thanks,
> ---
> Documentation/arm/mem_alignment | 2 +-
> arch/x86/kernel/kprobes/core.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/arm/mem_alignment b/Documentation/arm/mem_alignment
> index 6335fcacbba9..e110e2781039 100644
> --- a/Documentation/arm/mem_alignment
> +++ b/Documentation/arm/mem_alignment
> @@ -1,4 +1,4 @@
> -Too many problems poped up because of unnoticed misaligned memory access in
> +Too many problems popped up because of unnoticed misaligned memory access in
> kernel code lately. Therefore the alignment fixup is now unconditionally
> configured in for SA11x0 based targets. According to Alan Cox, this is a
> bad idea to configure it out, but Russell King has some good reasons for
> diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
> index 6afd8061dbae..d3243d93daf4 100644
> --- a/arch/x86/kernel/kprobes/core.c
> +++ b/arch/x86/kernel/kprobes/core.c
> @@ -813,7 +813,7 @@ __used __visible void *trampoline_handler(struct pt_regs *regs)
> continue;
> /*
> * Return probes must be pushed on this hash list correct
> - * order (same as return order) so that it can be poped
> + * order (same as return order) so that it can be popped
> * correctly. However, if we find it is pushed it incorrect
> * order, this means we find a function which should not be
> * probed, because the wrong order entry is pushed on the
> --
> 2.7.4
>
--
Masami Hiramatsu <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 2/2] ima: add enforce-evm and log-evm modes to strictly check EVM status
From: Mimi Zohar @ 2019-06-07 14:24 UTC (permalink / raw)
To: Roberto Sassu, dmitry.kasatkin, mjg59
Cc: linux-integrity, linux-security-module, linux-doc, stable,
linux-kernel, silviu.vlasceanu
In-Reply-To: <20190606112620.26488-3-roberto.sassu@huawei.com>
Hi Roberto,
Thank you for updating the patch description.
On Thu, 2019-06-06 at 13:26 +0200, Roberto Sassu wrote:
> IMA and EVM have been designed as two independent subsystems: the first for
> checking the integrity of file data; the second for checking file metadata.
> Making them independent allows users to adopt them incrementally.
>
> The point of intersection is in IMA-Appraisal, which calls
> evm_verifyxattr() to ensure that security.ima wasn't modified during an
> offline attack. The design choice, to ensure incremental adoption, was to
> continue appraisal verification if evm_verifyxattr() returns
> INTEGRITY_UNKNOWN. This value is returned when EVM is not enabled in the
> kernel configuration, or if the HMAC key has not been loaded yet.
>
> Although this choice appears legitimate, it might not be suitable for
> hardened systems, where the administrator expects that access is denied if
> there is any error. An attacker could intentionally delete the EVM keys
> from the system and set the file digest in security.ima to the actual file
> digest so that the final appraisal status is INTEGRITY_PASS.
Assuming that the EVM HMAC key is stored in the initramfs, not on some
other file system, and the initramfs is signed, INTEGRITY_UNKNOWN
would be limited to the rootfs filesystem.
>
> This patch allows such hardened systems to strictly enforce an access
> control policy based on the validity of signatures/HMACs, by introducing
> two new values for the ima_appraise= kernel option: enforce-evm and
> log-evm.
>
This patch defines a global policy requiring EVM on all filesystems.
I've previously suggested extending the IMA policy to support
enforcing or maybe exempting EVM on a per IMA policy rule basis. As
seen by the need for an additional patch, included in this patch set,
which defines a temporary random number HMAC key to address
INTEGRITY_UNKNOWN on the rootfs filesystem, exempting certain
filesystems on a per policy rule basis might be simpler and achieve
similar results.
I'd like to hear other people's thoughts on defining a temporary,
random number HMAC key.
thanks,
Mimi
^ permalink raw reply
* Re: [PATCH v3 2/2] ima: add enforce-evm and log-evm modes to strictly check EVM status
From: Roberto Sassu @ 2019-06-07 14:40 UTC (permalink / raw)
To: Mimi Zohar, dmitry.kasatkin, mjg59
Cc: linux-integrity, linux-security-module, linux-doc, stable,
linux-kernel, silviu.vlasceanu
In-Reply-To: <1559917462.4278.253.camel@linux.ibm.com>
On 6/7/2019 4:24 PM, Mimi Zohar wrote:
> Hi Roberto,
>
> Thank you for updating the patch description.
Hi Mimi
no problem.
> On Thu, 2019-06-06 at 13:26 +0200, Roberto Sassu wrote:
>> IMA and EVM have been designed as two independent subsystems: the first for
>> checking the integrity of file data; the second for checking file metadata.
>> Making them independent allows users to adopt them incrementally.
>>
>> The point of intersection is in IMA-Appraisal, which calls
>> evm_verifyxattr() to ensure that security.ima wasn't modified during an
>> offline attack. The design choice, to ensure incremental adoption, was to
>> continue appraisal verification if evm_verifyxattr() returns
>> INTEGRITY_UNKNOWN. This value is returned when EVM is not enabled in the
>> kernel configuration, or if the HMAC key has not been loaded yet.
>>
>> Although this choice appears legitimate, it might not be suitable for
>> hardened systems, where the administrator expects that access is denied if
>> there is any error. An attacker could intentionally delete the EVM keys
>> from the system and set the file digest in security.ima to the actual file
>> digest so that the final appraisal status is INTEGRITY_PASS.
>
> Assuming that the EVM HMAC key is stored in the initramfs, not on some
> other file system, and the initramfs is signed, INTEGRITY_UNKNOWN
> would be limited to the rootfs filesystem.
There is another issue. The HMAC key, like the public keys, should be
loaded when appraisal is disabled. This means that we have to create a
trusted key at early boot and defer the unsealing.
Roberto
--
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Bo PENG, Jian LI, Yanli SHI
^ permalink raw reply
* Re: [PATCH v3 2/2] ima: add enforce-evm and log-evm modes to strictly check EVM status
From: Mimi Zohar @ 2019-06-07 15:08 UTC (permalink / raw)
To: Roberto Sassu, dmitry.kasatkin, mjg59
Cc: linux-integrity, linux-security-module, linux-doc, stable,
linux-kernel, silviu.vlasceanu
In-Reply-To: <93459fe8-f9b6-fe45-1ca7-2efb8854dc8b@huawei.com>
On Fri, 2019-06-07 at 16:40 +0200, Roberto Sassu wrote:
> > On Thu, 2019-06-06 at 13:26 +0200, Roberto Sassu wrote:
> >> Although this choice appears legitimate, it might not be suitable for
> >> hardened systems, where the administrator expects that access is denied if
> >> there is any error. An attacker could intentionally delete the EVM keys
> >> from the system and set the file digest in security.ima to the actual file
> >> digest so that the final appraisal status is INTEGRITY_PASS.
> >
> > Assuming that the EVM HMAC key is stored in the initramfs, not on some
> > other file system, and the initramfs is signed, INTEGRITY_UNKNOWN
> > would be limited to the rootfs filesystem.
>
> There is another issue. The HMAC key, like the public keys, should be
> loaded when appraisal is disabled. This means that we have to create a
> trusted key at early boot and defer the unsealing.
There is no need for IMA to appraise the public key file signature,
since the certificate is signed by a key on the builtin/secondary
trusted keyring. With CONFIG_IMA_LOAD_X509 enabled, the public key
can be loaded onto the IMA keyring with IMA-appraisal enabled, but
without verifying the file signature.
Mimi
^ permalink raw reply
* Re: [PATCH v3 2/2] ima: add enforce-evm and log-evm modes to strictly check EVM status
From: Roberto Sassu @ 2019-06-07 15:14 UTC (permalink / raw)
To: Mimi Zohar, dmitry.kasatkin, mjg59
Cc: linux-integrity, linux-security-module, linux-doc, stable,
linux-kernel, silviu.vlasceanu
In-Reply-To: <1559920112.4278.264.camel@linux.ibm.com>
On 6/7/2019 5:08 PM, Mimi Zohar wrote:
> On Fri, 2019-06-07 at 16:40 +0200, Roberto Sassu wrote:
>>> On Thu, 2019-06-06 at 13:26 +0200, Roberto Sassu wrote:
>
>>>> Although this choice appears legitimate, it might not be suitable for
>>>> hardened systems, where the administrator expects that access is denied if
>>>> there is any error. An attacker could intentionally delete the EVM keys
>>>> from the system and set the file digest in security.ima to the actual file
>>>> digest so that the final appraisal status is INTEGRITY_PASS.
>>>
>>> Assuming that the EVM HMAC key is stored in the initramfs, not on some
>>> other file system, and the initramfs is signed, INTEGRITY_UNKNOWN
>>> would be limited to the rootfs filesystem.
>>
>> There is another issue. The HMAC key, like the public keys, should be
>> loaded when appraisal is disabled. This means that we have to create a
>> trusted key at early boot and defer the unsealing.
>
> There is no need for IMA to appraise the public key file signature,
> since the certificate is signed by a key on the builtin/secondary
> trusted keyring. With CONFIG_IMA_LOAD_X509 enabled, the public key
> can be loaded onto the IMA keyring with IMA-appraisal enabled, but
> without verifying the file signature.
Yes, but access to the files containing the master key and the EVM key
is denied if appraisal is enabled.
Roberto
--
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Bo PENG, Jian LI, Yanli SHI
^ permalink raw reply
* [PATCH 0/4] Documentation: x86: resctrl_ui.txt fixes and clarification
From: James Morse @ 2019-06-07 15:14 UTC (permalink / raw)
To: linux-doc, x86
Cc: Jonathan Corbet, Reinette Chatre, Fenghua Yu, Babu Moger,
linux-kernel, James Morse
While updating resctrl_ui.rst for arm64 support these things stuck
out as being unclear or no longer true.
(I've shortened the CC list to just RDT+Documentation)
Thanks,
James Morse (4):
Documentation: x86: Contiguous cbm isn't all X86
Documentation: x86: Remove cdpl2 unspported statement and fix
capitalisation
Documentation: x86: Clarify MBA takes MB as referring to mba_sc
Documentation: x86: fix some typos
Documentation/x86/resctrl_ui.rst | 30 ++++++++++++++++++------------
1 file changed, 18 insertions(+), 12 deletions(-)
--
2.20.1
^ permalink raw reply
* [PATCH 1/4] Documentation: x86: Contiguous cbm isn't all X86
From: James Morse @ 2019-06-07 15:14 UTC (permalink / raw)
To: linux-doc, x86
Cc: Jonathan Corbet, Reinette Chatre, Fenghua Yu, Babu Moger,
linux-kernel, James Morse
In-Reply-To: <20190607151409.15476-1-james.morse@arm.com>
Since commit 4d05bf71f157 ("x86/resctrl: Introduce AMD QOS feature")
resctrl has supported non-contiguous cache bit masks. The interface
for this is currently try-it-and-see.
Update the documentation to say Intel CPUs have this requirement,
instead of X86.
Cc: Babu Moger <Babu.Moger@amd.com>
Signed-off-by: James Morse <james.morse@arm.com>
---
Documentation/x86/resctrl_ui.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/x86/resctrl_ui.rst b/Documentation/x86/resctrl_ui.rst
index 225cfd4daaee..066f94e53418 100644
--- a/Documentation/x86/resctrl_ui.rst
+++ b/Documentation/x86/resctrl_ui.rst
@@ -342,7 +342,7 @@ For cache resources we describe the portion of the cache that is available
for allocation using a bitmask. The maximum value of the mask is defined
by each cpu model (and may be different for different cache levels). It
is found using CPUID, but is also provided in the "info" directory of
-the resctrl file system in "info/{resource}/cbm_mask". X86 hardware
+the resctrl file system in "info/{resource}/cbm_mask". Intel hardware
requires that these masks have all the '1' bits in a contiguous block. So
0x3, 0x6 and 0xC are legal 4-bit masks with two bits set, but 0x5, 0x9
and 0xA are not. On a system with a 20-bit mask each bit represents 5%
--
2.20.1
^ permalink raw reply related
* [PATCH 2/4] Documentation: x86: Remove cdpl2 unspported statement and fix capitalisation
From: James Morse @ 2019-06-07 15:14 UTC (permalink / raw)
To: linux-doc, x86
Cc: Jonathan Corbet, Reinette Chatre, Fenghua Yu, Babu Moger,
linux-kernel, James Morse
In-Reply-To: <20190607151409.15476-1-james.morse@arm.com>
"L2 cache does not support code and data prioritization". This isn't
true, elsewhere the document says it can be enabled with the cdpl2
mount option.
While we're here, these sample strings have lower-case code/data,
which isn't how the kernel exports them.
Signed-off-by: James Morse <james.morse@arm.com>
---
Documentation/x86/resctrl_ui.rst | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/Documentation/x86/resctrl_ui.rst b/Documentation/x86/resctrl_ui.rst
index 066f94e53418..638cd987937d 100644
--- a/Documentation/x86/resctrl_ui.rst
+++ b/Documentation/x86/resctrl_ui.rst
@@ -418,16 +418,22 @@ L3 schemata file details (CDP enabled via mount option to resctrl)
When CDP is enabled L3 control is split into two separate resources
so you can specify independent masks for code and data like this::
- L3data:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
- L3code:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
+ L3DATA:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
+ L3CODE:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
L2 schemata file details
------------------------
-L2 cache does not support code and data prioritization, so the
-schemata format is always::
+CDP is supported at L2 using the 'cdpl2' mount option. The schemata
+format is either::
L2:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
+or
+
+ L2DATA:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
+ L2CODE:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
+
+
Memory bandwidth Allocation (default mode)
------------------------------------------
--
2.20.1
^ permalink raw reply related
* [PATCH 3/4] Documentation: x86: Clarify MBA takes MB as referring to mba_sc
From: James Morse @ 2019-06-07 15:14 UTC (permalink / raw)
To: linux-doc, x86
Cc: Jonathan Corbet, Reinette Chatre, Fenghua Yu, Babu Moger,
linux-kernel, James Morse
In-Reply-To: <20190607151409.15476-1-james.morse@arm.com>
"If the MBA is specified in MB then user can enter the max b/w in MB"
is a tautology. How can the user know if the schemata takes a percentage
or a MB/s value?
This is referring to whether the software controller is interpreting
the schemata's value. Make this clear.
Signed-off-by: James Morse <james.morse@arm.com>
---
Documentation/x86/resctrl_ui.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/x86/resctrl_ui.rst b/Documentation/x86/resctrl_ui.rst
index 638cd987937d..866b66aa289b 100644
--- a/Documentation/x86/resctrl_ui.rst
+++ b/Documentation/x86/resctrl_ui.rst
@@ -677,8 +677,8 @@ allocations can overlap or not. The allocations specifies the maximum
b/w that the group may be able to use and the system admin can configure
the b/w accordingly.
-If the MBA is specified in MB(megabytes) then user can enter the max b/w in MB
-rather than the percentage values.
+If resctrl is using the software controller (mba_sc) then user can enter the
+max b/w in MB rather than the percentage values.
::
# echo "L3:0=3;1=c\nMB:0=1024;1=500" > /sys/fs/resctrl/p0/schemata
--
2.20.1
^ permalink raw reply related
* [PATCH 4/4] Documentation: x86: fix some typos
From: James Morse @ 2019-06-07 15:14 UTC (permalink / raw)
To: linux-doc, x86
Cc: Jonathan Corbet, Reinette Chatre, Fenghua Yu, Babu Moger,
linux-kernel, James Morse
In-Reply-To: <20190607151409.15476-1-james.morse@arm.com>
These are all obvious typos.
Signed-off-by: James Morse <james.morse@arm.com>
---
Documentation/x86/resctrl_ui.rst | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/x86/resctrl_ui.rst b/Documentation/x86/resctrl_ui.rst
index 866b66aa289b..5368cedfb530 100644
--- a/Documentation/x86/resctrl_ui.rst
+++ b/Documentation/x86/resctrl_ui.rst
@@ -40,7 +40,7 @@ mount options are:
Enable the MBA Software Controller(mba_sc) to specify MBA
bandwidth in MBps
-L2 and L3 CDP are controlled seperately.
+L2 and L3 CDP are controlled separately.
RDT features are orthogonal. A particular system may support only
monitoring, only control, or both monitoring and control. Cache
@@ -118,7 +118,7 @@ related to allocation:
Corresponding region is pseudo-locked. No
sharing allowed.
-Memory bandwitdh(MB) subdirectory contains the following files
+Memory bandwidth(MB) subdirectory contains the following files
with respect to allocation:
"min_bandwidth":
@@ -209,7 +209,7 @@ All groups contain the following files:
CPUs to/from this group. As with the tasks file a hierarchy is
maintained where MON groups may only include CPUs owned by the
parent CTRL_MON group.
- When the resouce group is in pseudo-locked mode this file will
+ When the resource group is in pseudo-locked mode this file will
only be readable, reflecting the CPUs associated with the
pseudo-locked region.
@@ -380,7 +380,7 @@ where L2 external is 10GBps (hence aggregate L2 external bandwidth is
240GBps) and L3 external bandwidth is 100GBps. Now a workload with '20
threads, having 50% bandwidth, each consuming 5GBps' consumes the max L3
bandwidth of 100GBps although the percentage value specified is only 50%
-<< 100%. Hence increasing the bandwidth percentage will not yeild any
+<< 100%. Hence increasing the bandwidth percentage will not yield any
more bandwidth. This is because although the L2 external bandwidth still
has capacity, the L3 external bandwidth is fully used. Also note that
this would be dependent on number of cores the benchmark is run on.
@@ -398,7 +398,7 @@ In order to mitigate this and make the interface more user friendly,
resctrl added support for specifying the bandwidth in MBps as well. The
kernel underneath would use a software feedback mechanism or a "Software
Controller(mba_sc)" which reads the actual bandwidth using MBM counters
-and adjust the memowy bandwidth percentages to ensure::
+and adjust the memory bandwidth percentages to ensure::
"actual bandwidth < user specified bandwidth".
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v3 2/2] ima: add enforce-evm and log-evm modes to strictly check EVM status
From: Mimi Zohar @ 2019-06-07 15:25 UTC (permalink / raw)
To: Roberto Sassu, dmitry.kasatkin, mjg59
Cc: linux-integrity, linux-security-module, linux-doc, linux-kernel,
silviu.vlasceanu
In-Reply-To: <773c3301-7861-f28b-813a-1f2ff657bae8@huawei.com>
On Fri, 2019-06-07 at 17:14 +0200, Roberto Sassu wrote:
> On 6/7/2019 5:08 PM, Mimi Zohar wrote:
> > On Fri, 2019-06-07 at 16:40 +0200, Roberto Sassu wrote:
> >>> On Thu, 2019-06-06 at 13:26 +0200, Roberto Sassu wrote:
> >
> >>>> Although this choice appears legitimate, it might not be suitable for
> >>>> hardened systems, where the administrator expects that access is denied if
> >>>> there is any error. An attacker could intentionally delete the EVM keys
> >>>> from the system and set the file digest in security.ima to the actual file
> >>>> digest so that the final appraisal status is INTEGRITY_PASS.
> >>>
> >>> Assuming that the EVM HMAC key is stored in the initramfs, not on some
> >>> other file system, and the initramfs is signed, INTEGRITY_UNKNOWN
> >>> would be limited to the rootfs filesystem.
> >>
> >> There is another issue. The HMAC key, like the public keys, should be
> >> loaded when appraisal is disabled. This means that we have to create a
> >> trusted key at early boot and defer the unsealing.
> >
> > There is no need for IMA to appraise the public key file signature,
> > since the certificate is signed by a key on the builtin/secondary
> > trusted keyring. With CONFIG_IMA_LOAD_X509 enabled, the public key
> > can be loaded onto the IMA keyring with IMA-appraisal enabled, but
> > without verifying the file signature.
>
> Yes, but access to the files containing the master key and the EVM key
> is denied if appraisal is enabled.
This is a key loading ordering issue. Assuming you load the IMA key
first, you should be able to verify the master and EVM keys.
Mimi
^ permalink raw reply
* Re: [PATCH v7 05/27] x86/fpu/xstate: Add XSAVES system states for shadow stack
From: Yu-cheng Yu @ 2019-06-07 16:14 UTC (permalink / raw)
To: Peter Zijlstra
Cc: x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar, linux-kernel,
linux-doc, linux-mm, linux-arch, linux-api, Arnd Bergmann,
Andy Lutomirski, Balbir Singh, Borislav Petkov, Cyrill Gorcunov,
Dave Hansen, Eugene Syromiatnikov, Florian Weimer, H.J. Lu,
Jann Horn, Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pavel Machek, Randy Dunlap, Ravi V. Shankar,
Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <20190607070725.GN3419@hirez.programming.kicks-ass.net>
On Fri, 2019-06-07 at 09:07 +0200, Peter Zijlstra wrote:
> On Thu, Jun 06, 2019 at 01:06:24PM -0700, Yu-cheng Yu wrote:
> > Intel Control-flow Enforcement Technology (CET) introduces the
> > following MSRs.
> >
> > MSR_IA32_U_CET (user-mode CET settings),
> > MSR_IA32_PL3_SSP (user-mode shadow stack),
> > MSR_IA32_PL0_SSP (kernel-mode shadow stack),
> > MSR_IA32_PL1_SSP (Privilege Level 1 shadow stack),
> > MSR_IA32_PL2_SSP (Privilege Level 2 shadow stack).
> >
> > Introduce them into XSAVES system states.
> >
> > Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
> > ---
> > arch/x86/include/asm/fpu/types.h | 22 +++++++++++++++++++++
> > arch/x86/include/asm/fpu/xstate.h | 4 +++-
> > arch/x86/include/uapi/asm/processor-flags.h | 2 ++
> > arch/x86/kernel/fpu/xstate.c | 10 ++++++++++
> > 4 files changed, 37 insertions(+), 1 deletion(-)
>
> And yet, no changes to msr-index.h !?
You are right. I will move msr-index.h changes to here.
Yu-cheng
^ permalink raw reply
* Re: [PATCH v7 18/27] mm: Introduce do_mmap_locked()
From: Yu-cheng Yu @ 2019-06-07 16:16 UTC (permalink / raw)
To: Peter Zijlstra
Cc: x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar, linux-kernel,
linux-doc, linux-mm, linux-arch, linux-api, Arnd Bergmann,
Andy Lutomirski, Balbir Singh, Borislav Petkov, Cyrill Gorcunov,
Dave Hansen, Eugene Syromiatnikov, Florian Weimer, H.J. Lu,
Jann Horn, Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pavel Machek, Randy Dunlap, Ravi V. Shankar,
Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <20190607074707.GD3463@hirez.programming.kicks-ass.net>
On Fri, 2019-06-07 at 09:47 +0200, Peter Zijlstra wrote:
> On Fri, Jun 07, 2019 at 09:43:22AM +0200, Peter Zijlstra wrote:
> > On Thu, Jun 06, 2019 at 01:06:37PM -0700, Yu-cheng Yu wrote:
> > > There are a few places that need do_mmap() with mm->mmap_sem held.
> > > Create an in-line function for that.
> > >
> > > Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
> > > ---
> > > include/linux/mm.h | 18 ++++++++++++++++++
> > > 1 file changed, 18 insertions(+)
> > >
> > > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > > index 398f1e1c35e5..7cf014604848 100644
> > > --- a/include/linux/mm.h
> > > +++ b/include/linux/mm.h
> > > @@ -2411,6 +2411,24 @@ static inline void mm_populate(unsigned long addr,
> > > unsigned long len)
> > > static inline void mm_populate(unsigned long addr, unsigned long len) {}
> > > #endif
> > >
> > > +static inline unsigned long do_mmap_locked(unsigned long addr,
> > > + unsigned long len, unsigned long prot, unsigned long flags,
> > > + vm_flags_t vm_flags)
> > > +{
> > > + struct mm_struct *mm = current->mm;
> > > + unsigned long populate;
> > > +
> > > + down_write(&mm->mmap_sem);
> > > + addr = do_mmap(NULL, addr, len, prot, flags, vm_flags, 0,
> > > + &populate, NULL);
> >
> > Funny thing how do_mmap() takes a file pointer as first argument and
> > this thing explicitly NULLs that. That more or less invalidates the name
> > do_mmap_locked().
> >
> > > + up_write(&mm->mmap_sem);
> > > +
> > > + if (populate)
> > > + mm_populate(addr, populate);
> > > +
> > > + return addr;
> > > +}
>
> You also don't retain that last @uf argument.
>
> I'm thikning you're better off adding a helper to the cet.c file; call
> it cet_mmap() or whatever.
Ok, I will fix that.
Yu-cheng
^ permalink raw reply
* Re: [PATCH v7 22/27] binfmt_elf: Extract .note.gnu.property from an ELF file
From: Yu-cheng Yu @ 2019-06-07 16:17 UTC (permalink / raw)
To: Peter Zijlstra
Cc: x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar, linux-kernel,
linux-doc, linux-mm, linux-arch, linux-api, Arnd Bergmann,
Andy Lutomirski, Balbir Singh, Borislav Petkov, Cyrill Gorcunov,
Dave Hansen, Eugene Syromiatnikov, Florian Weimer, H.J. Lu,
Jann Horn, Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pavel Machek, Randy Dunlap, Ravi V. Shankar,
Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <20190607075822.GR3419@hirez.programming.kicks-ass.net>
On Fri, 2019-06-07 at 09:58 +0200, Peter Zijlstra wrote:
> On Thu, Jun 06, 2019 at 01:06:41PM -0700, Yu-cheng Yu wrote:
> > An ELF file's .note.gnu.property indicates features the executable file
> > can support. For example, the property GNU_PROPERTY_X86_FEATURE_1_AND
> > indicates the file supports GNU_PROPERTY_X86_FEATURE_1_IBT and/or
> > GNU_PROPERTY_X86_FEATURE_1_SHSTK.
> >
> > With this patch, if an arch needs to setup features from ELF properties,
> > it needs CONFIG_ARCH_USE_GNU_PROPERTY to be set, and a specific
> > arch_setup_property().
> >
> > For example, for X86_64:
> >
> > int arch_setup_property(void *ehdr, void *phdr, struct file *f, bool inter)
> > {
> > int r;
> > uint32_t property;
> >
> > r = get_gnu_property(ehdr, phdr, f, GNU_PROPERTY_X86_FEATURE_1_AND,
> > &property);
> > ...
> > }
> >
> > Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
> > Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
>
> Did HJ write this patch as suggested by that SoB chain? If so, you lost
> a From: line on top, if not, the SoB thing is invalid.
I will fix that.
Yu-cheng
^ permalink raw reply
* Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
From: Yu-cheng Yu @ 2019-06-07 16:23 UTC (permalink / raw)
To: Peter Zijlstra
Cc: x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar, linux-kernel,
linux-doc, linux-mm, linux-arch, linux-api, Arnd Bergmann,
Andy Lutomirski, Balbir Singh, Borislav Petkov, Cyrill Gorcunov,
Dave Hansen, Eugene Syromiatnikov, Florian Weimer, H.J. Lu,
Jann Horn, Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pavel Machek, Randy Dunlap, Ravi V. Shankar,
Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <20190607080832.GT3419@hirez.programming.kicks-ass.net>
On Fri, 2019-06-07 at 10:08 +0200, Peter Zijlstra wrote:
> On Thu, Jun 06, 2019 at 01:09:15PM -0700, Yu-cheng Yu wrote:
> > Indirect Branch Tracking (IBT) provides an optional legacy code bitmap
> > that allows execution of legacy, non-IBT compatible library by an
> > IBT-enabled application. When set, each bit in the bitmap indicates
> > one page of legacy code.
> >
> > The bitmap is allocated and setup from the application.
> > +int cet_setup_ibt_bitmap(unsigned long bitmap, unsigned long size)
> > +{
> > + u64 r;
> > +
> > + if (!current->thread.cet.ibt_enabled)
> > + return -EINVAL;
> > +
> > + if (!PAGE_ALIGNED(bitmap) || (size > TASK_SIZE_MAX))
> > + return -EINVAL;
> > +
> > + current->thread.cet.ibt_bitmap_addr = bitmap;
> > + current->thread.cet.ibt_bitmap_size = size;
> > +
> > + /*
> > + * Turn on IBT legacy bitmap.
> > + */
> > + modify_fpu_regs_begin();
> > + rdmsrl(MSR_IA32_U_CET, r);
> > + r |= (MSR_IA32_CET_LEG_IW_EN | bitmap);
> > + wrmsrl(MSR_IA32_U_CET, r);
> > + modify_fpu_regs_end();
> > +
> > + return 0;
> > +}
>
> So you just program a random user supplied address into the hardware.
> What happens if there's not actually anything at that address or the
> user munmap()s the data after doing this?
This function checks the bitmap's alignment and size, and anything else is the
app's responsibility. What else do you think the kernel should check?
Yu-cheng
^ permalink raw reply
* Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
From: Andy Lutomirski @ 2019-06-07 16:35 UTC (permalink / raw)
To: Yu-cheng Yu
Cc: Peter Zijlstra, x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar,
linux-kernel, linux-doc, linux-mm, linux-arch, linux-api,
Arnd Bergmann, Balbir Singh, Borislav Petkov, Cyrill Gorcunov,
Dave Hansen, Eugene Syromiatnikov, Florian Weimer, H.J. Lu,
Jann Horn, Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pavel Machek, Randy Dunlap, Ravi V. Shankar,
Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <aa8a92ef231d512b5c9855ef416db050b5ab59a6.camel@intel.com>
> On Jun 7, 2019, at 9:23 AM, Yu-cheng Yu <yu-cheng.yu@intel.com> wrote:
>
>> On Fri, 2019-06-07 at 10:08 +0200, Peter Zijlstra wrote:
>>> On Thu, Jun 06, 2019 at 01:09:15PM -0700, Yu-cheng Yu wrote:
>>> Indirect Branch Tracking (IBT) provides an optional legacy code bitmap
>>> that allows execution of legacy, non-IBT compatible library by an
>>> IBT-enabled application. When set, each bit in the bitmap indicates
>>> one page of legacy code.
>>>
>>> The bitmap is allocated and setup from the application.
>>> +int cet_setup_ibt_bitmap(unsigned long bitmap, unsigned long size)
>>> +{
>>> + u64 r;
>>> +
>>> + if (!current->thread.cet.ibt_enabled)
>>> + return -EINVAL;
>>> +
>>> + if (!PAGE_ALIGNED(bitmap) || (size > TASK_SIZE_MAX))
>>> + return -EINVAL;
>>> +
>>> + current->thread.cet.ibt_bitmap_addr = bitmap;
>>> + current->thread.cet.ibt_bitmap_size = size;
>>> +
>>> + /*
>>> + * Turn on IBT legacy bitmap.
>>> + */
>>> + modify_fpu_regs_begin();
>>> + rdmsrl(MSR_IA32_U_CET, r);
>>> + r |= (MSR_IA32_CET_LEG_IW_EN | bitmap);
>>> + wrmsrl(MSR_IA32_U_CET, r);
>>> + modify_fpu_regs_end();
>>> +
>>> + return 0;
>>> +}
>>
>> So you just program a random user supplied address into the hardware.
>> What happens if there's not actually anything at that address or the
>> user munmap()s the data after doing this?
>
> This function checks the bitmap's alignment and size, and anything else is the
> app's responsibility. What else do you think the kernel should check?
>
One might reasonably wonder why this state is privileged in the first place and, given that, why we’re allowing it to be written like this.
Arguably we should have another prctl to lock these values (until exec) as a gardening measure.
^ permalink raw reply
* Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
From: Dave Hansen @ 2019-06-07 16:39 UTC (permalink / raw)
To: Andy Lutomirski, Yu-cheng Yu
Cc: Peter Zijlstra, x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar,
linux-kernel, linux-doc, linux-mm, linux-arch, linux-api,
Arnd Bergmann, Balbir Singh, Borislav Petkov, Cyrill Gorcunov,
Dave Hansen, Eugene Syromiatnikov, Florian Weimer, H.J. Lu,
Jann Horn, Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pavel Machek, Randy Dunlap, Ravi V. Shankar,
Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <76B7B1AE-3AEA-4162-B539-990EF3CCE2C2@amacapital.net>
On 6/7/19 9:35 AM, Andy Lutomirski wrote:
> One might reasonably wonder why this state is privileged in the first
> place and, given that, why we’re allowing it to be written like
> this.
I think it's generally a good architectural practice to make things like
this privileged. They're infrequent so can survive the cost of a trip
in/out of the kernel and are a great choke point to make sure the OS is
involved. I wish we had the same for MPX or pkeys per-task "setup".
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox