On 2018-11-08, Aleksa Sarai wrote:
> I will attach what I have at the moment to hopefully explain what the
> issue I've found is (re-using the kretprobe architecture but with the
> shadow-stack idea).
Here is the patch I have at the moment (it works, except for the
question I have about how to ha
On Wed, Nov 07, 2018 at 01:32:29PM -0800, Tejun Heo wrote:
> How about the following?
>
> Interface file is named "cpuset.cpus.partition" as it's a partition of
> cpus. The writeable keys are "root" and "member" - a partition root
> and a partition member. When "root" is requested but can't be
From: Martin Steigerwald
> Sent: 07 November 2018 17:05
...
> Its not quite on-topic, but I am curious now: AFAIK PID limit is 16
> bits. Right? Could it be raised to 32 bits? I bet it would be a major
> change throughout different parts of the kernel.
It is probably 15 bits (since -ve pid numbers
On Tue, Nov 06, 2018 at 06:30:27PM +0100, Andrey Konovalov wrote:
> show_pte in arm64 fault handling relies on the fact that the top byte of
> a kernel pointer is 0xff, which isn't always the case with tag-based
> KASAN.
That's for the TTBR1 check, right?
i.e. for the following to work:
On Thu, Nov 08, 2018 at 12:02:49PM +, David Laight wrote:
> From: Martin Steigerwald
> > Sent: 07 November 2018 17:05
> ...
> > Its not quite on-topic, but I am curious now: AFAIK PID limit is 16
> > bits. Right? Could it be raised to 32 bits? I bet it would be a major
> > change throughout dif
On Wed 07-11-18 18:04:59, Martin Steigerwald wrote:
> Michal Hocko - 07.11.18, 17:00:
> > > > otherwise anybody could simply DoS the system
> > > > by consuming all available pids.
> > >
> > > People can do that today using the instrument of terror widely known
> > > as fork(2). The only thing sta
From: Matthew Wilcox
> Sent: 08 November 2018 12:28
>
> On Thu, Nov 08, 2018 at 12:02:49PM +, David Laight wrote:
> > From: Martin Steigerwald
> > > Sent: 07 November 2018 17:05
> > ...
> > > Its not quite on-topic, but I am curious now: AFAIK PID limit is 16
> > > bits. Right? Could it be rais
On Thu, Nov 08, 2018 at 01:42:41PM +, David Laight wrote:
> From: Matthew Wilcox
> > On Thu, Nov 08, 2018 at 12:02:49PM +, David Laight wrote:
> > > This can be mitigated by only allocating 'big' numbers on systems
> > > that have a lot of pids.
> > > You also really want an O(1) allocator.
From: Matthew Wilcox
> Sent: 08 November 2018 14:07
...
>
> You'd be looking for something like dynamic perfect hashing then?
> I think that'd make a great project for someone to try out. I don't
> have the time to look into it myself, and I'm not convinced there's
> a real workload that would be
mm/gup.c provides a kernel interface that accepts user addresses and
manipulates user pages directly (for example get_user_pages, that is used
by the futex syscall). Since a user can provided tagged addresses, we need
to handle such case.
Add untagging to gup.c functions that use user addresses fo
strncpy_from_user and strnlen_user accept user addresses as arguments, and
do not go through the same path as copy_from_user and others, so here we
need to handle the case of tagged user addresses separately.
Untag user pointers passed to these functions.
Signed-off-by: Andrey Konovalov
---
lib
This patch adds a simple test, that calls the uname syscall with a
tagged user pointer as an argument. Without the kernel accepting tagged
user pointers the test fails with EFAULT.
Signed-off-by: Andrey Konovalov
---
tools/testing/selftests/arm64/.gitignore | 1 +
tools/testing/selftests/a
arm64 has a feature called Top Byte Ignore, which allows to embed pointer
tags into the top byte of each pointer. Userspace programs (such as
HWASan, a memory debugging tool [1]) might use this feature and pass
tagged user pointers to the kernel through syscalls or other interfaces.
Right now the
In copy_mount_options a user address is being subtracted from TASK_SIZE.
If the address is lower than TASK_SIZE, the size is calculated to not
allow the exact_copy_from_user() call to cross TASK_SIZE boundary.
However if the address is tagged, then the size will be calculated
incorrectly.
Untag th
copy_from_user (and a few other similar functions) are used to copy data
from user memory into the kernel memory or vice versa. Since a user can
provided a tagged pointer to one of the syscalls that use copy_from_user,
we need to correctly handle such pointers.
Do this by untagging user pointers i
Document the changes in Documentation/arm64/tagged-pointers.txt.
Signed-off-by: Andrey Konovalov
---
Documentation/arm64/tagged-pointers.txt | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/Documentation/arm64/tagged-pointers.txt
b/Documentation/ar
To allow arm64 syscalls accept tagged pointers from userspace, we must
untag them when they are passed to the kernel. Since untagging is done in
generic parts of the kernel, the untagged_addr macro needs to be defined
for all architectures.
Define it as a noop for other architectures besides arm64
This patch makes the untagged_addr macro accept all kinds of address types
(void *, unsigned long, etc.) and allows not to specify type casts in each
place where it is used. This is done by using __typeof__.
Signed-off-by: Andrey Konovalov
---
arch/arm64/include/asm/uaccess.h | 3 ++-
1 file cha
On Wed, Nov 07, 2018 at 09:09:37AM -0800, Dave Hansen wrote:
> On 11/7/18 8:30 AM, Jarkko Sakkinen wrote:
> >> Does this code run when I type "make kselftest"? If not, I think we
> >> should rectify that.
> > No, it doesn't. It is just my backup for the non-SDK user space code
> > that I've made t
On Thu, Nov 08, 2018 at 07:04:48PM +1100, Aleksa Sarai wrote:
> On 2018-11-08, Aleksa Sarai wrote:
> > I will attach what I have at the moment to hopefully explain what the
> > issue I've found is (re-using the kretprobe architecture but with the
> > shadow-stack idea).
>
> Here is the patch I ha
On Thu, Nov 8, 2018 at 3:36 PM, Andrey Konovalov wrote:
[...]
> Changes in v8:
> - Rebased onto 65102238 (4.20-rc1).
> - Added a note to the cover letter on why syscall wrappers/shims that untag
> user pointers won't work.
> - Added a note to the cover letter that this patchset has been merged
v15:
- Change the partition state descriptive text to "root", "member" and
"root invalid" as suggested by Tejun.
- Move the descriptive text patch up to before the documentation patch.
- Address comments raised by PeterZ.
v14:
- Fix a bug about cpumask handling in patch 4 by using
CONFIG
>From a cpuset point of view, a scheduling partition is a group of
cpusets with their own set of exclusive CPUs that are not shared by
other tasks outside the scheduling partition.
In the legacy hierarchy, scheduling partitions are supported indirectly
via the right use of the load balancing and t
The generate_sched_domains() function is modified to make it work
correctly with the newly introduced subparts_cpus mask for scheduling
domains generation.
Signed-off-by: Waiman Long
---
kernel/cgroup/cpuset.c | 34 +++---
1 file changed, 27 insertions(+), 7 deletions
When external events like CPU offlining or user events like changing
the cpu list of an ancestor cpuset happen, update_cpumasks_hier()
will be called to update the effective cpus of each of the affected
cpusets. That will then call update_parent_subparts_cpumask() if
partitions are impacted.
Curre
For debugging purpose, it will be useful to expose the content of the
subparts_cpus as a read-only file to see if the code work correctly.
However, subparts_cpus will not be used at all in most use cases. So
adding a new cpuset file that clutters the cgroup directory may not be
desirable. This is
Currently, cpuset.sched.partition returns the values, 0, 1 or -1 on
read. A person who is not familiar with the partition code may not
understand what they mean.
In order to make cpuset.sched.partition more user-friendly, it will
now display the following descriptive text on read:
"root" - A pa
The cgroup-v2.rst file is updated to document the purpose of the new
"cpuset.sched.partition" flag and how its usage.
Signed-off-by: Waiman Long
---
Documentation/admin-guide/cgroup-v2.rst | 73 +
1 file changed, 73 insertions(+)
diff --git a/Documentation/admin-
Given the fact that thread mode had been merged into 4.14, it is now
time to enable cpuset to be used in the default hierarchy (cgroup v2)
as it is clearly threaded.
The cpuset controller had experienced feature creep since its
introduction more than a decade ago. Besides the core cpus and mems
co
A new cpuset.sched.partition boolean flag is added to cpuset v2.
This new flag, if set, indicates that the cgroup is the root of a
new scheduling domain or partition that includes itself and all its
descendants except those that are scheduling domain roots themselves
and their descendants.
With th
When there is a cpu hotplug event (CPU online or offline), the partitions
may need to be reconfigured and regenerated. So code is added to the
hotplug functions to make them work with new subparts_cpus mask to
compute the right effective_cpus for each of the affected cpusets.
It may also change the
The previous commit introduces a new subparts_cpus mask into the cpuset
data structure and a new tmpmasks structure. Managing the allocation
and freeing of those cpumasks is becoming more complex.
So a number of helper functions are added to simplify and streamline
the management of those cpumask
In the default hierarchy, a cpuset will use the parent's effective_cpus
if none of the requested CPUs can be granted from the parent. That can
be a problem if a parent is a partition root with children partition
roots. Changes to a parent's effective_cpus list due to changes in a
child partition ro
Because of the fact that setting the "cpuset.sched.partition" in
a direct child of root can remove CPUs from the root's effective CPU
list, it makes sense to know what CPUs are left in the root cgroup for
scheduling purpose. So the "cpuset.cpus.effective" control file is now
exposed in the v2 cgrou
On Thu, Nov 08, 2018 at 10:08:34AM -0500, Waiman Long wrote:
> Waiman Long (12):
> cpuset: Enable cpuset controller in default hierarchy
> cpuset: Define data structures to support scheduling partition
> cpuset: Simply allocation and freeing of cpumasks
> cpuset: Add new v2 cpuset.sched.par
On Thu, Nov 08, 2018 at 10:08:46AM -0500, Waiman Long wrote:
> For debugging purpose, it will be useful to expose the content of the
> subparts_cpus as a read-only file to see if the code work correctly.
> However, subparts_cpus will not be used at all in most use cases. So
> adding a new cpuset fi
On Tue, Nov 06, 2018 at 03:01:15PM -0800, Mark Salyzyn wrote:
> By default, all access to the upper, lower and work directories is the
> recorded mounter's MAC and DAC credentials. The incoming accesses are
> checked against the caller's credentials.
>
> If the principles of least privilege are a
This patch series is a proposal for the I3C master driver for Synopsys IP.
This patch is to be applied on top of I3C subsystem RFC V10 submitted by
Boris Brezillon.
Supported features:
Regular CCC commands.
I3C private transfers.
I2C transfers.
Missing functionalities:
Support DMA interfa
Add driver for Synopsys DesignWare I3C master IP
Signed-off-by: Vitor soares
---
Change in v3:
- Use struct_size() (suggested by Matthew)
Change in v2:
- Rename some variables
- Remove dw_i3c_master_dev_set_info()
- Ajust code to match the changes made of i3c subsystem
- Use readsl/writesl() to
Document Synopsys DesignWare I3C master module
Signed-off-by: Vitor soares
---
Changes in v3:
- Remove dummy characters
Changes in v2:
- Address the changes in Documentation/devicetree/bindings/i3c/i3c.txt
- Add controller version on compatible string
.../devicetree/bindings/i3c/snps,dw-i3c-ma
Signed-off-by: Vitor soares
---
Change in v3:
- Remove dummy characters
Change in v2:
- None
MAINTAINERS | 6 ++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 293c863..39910b3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6930,6 +6930,12 @@ F: drivers/
On Thu, Oct 11, 2018 at 08:15:00AM -0700, Yu-cheng Yu wrote:
> Intel Control-flow Enforcement Technology (CET) introduces the
> following MSRs into the XSAVES system states.
>
> IA32_U_CET (user-mode CET settings),
> IA32_PL3_SSP (user-mode shadow stack),
> IA32_PL0_SSP (kernel-mode sh
On 11/08/2018 10:46 AM, Peter Zijlstra wrote:
> On Thu, Nov 08, 2018 at 10:08:46AM -0500, Waiman Long wrote:
>> For debugging purpose, it will be useful to expose the content of the
>> subparts_cpus as a read-only file to see if the code work correctly.
>> However, subparts_cpus will not be used at
On Thu, Nov 08, 2018 at 04:39:42PM +0200, Jarkko Sakkinen wrote:
> On Wed, Nov 07, 2018 at 09:09:37AM -0800, Dave Hansen wrote:
> > On 11/7/18 8:30 AM, Jarkko Sakkinen wrote:
> > >> Does this code run when I type "make kselftest"? If not, I think we
> > >> should rectify that.
> > > No, it doesn't
On Tue, Nov 06, 2018 at 03:01:15PM -0800, Mark Salyzyn wrote:
> By default, all access to the upper, lower and work directories is the
> recorded mounter's MAC and DAC credentials. The incoming accesses are
> checked against the caller's credentials.
Ok, I am trying to think of scenarios where ov
On 04/11/2018 18:11, Ahmed Abd El Mawgood wrote:
> Our model assumes that an attacker got full root access to a running guest and
> his goal is to manipulate kernel code/data (hook syscalls, overwrite IDT
> ..etc).
>
> There is future work in progress to also put some sort of protection on the
>
Applied to cgroup/for-4.21.
Thanks a lot, Waiman!
--
tejun
On 11/08/2018 03:28 PM, Tejun Heo wrote:
> Applied to cgroup/for-4.21.
>
> Thanks a lot, Waiman!
>
Thanks for applying it. It is a long way to get to this point.
Cheers,
Longman
On Thu, 2018-11-08 at 19:40 +0100, Borislav Petkov wrote:
> On Thu, Oct 11, 2018 at 08:15:00AM -0700, Yu-cheng Yu wrote:
> > [...]
> > +/*
> > + * State component 11 is Control flow Enforcement user states
>
> Why the Camel-cased naming?
>
> "Control" then "flow" then capitalized again "Enforcem
On Thu, Oct 11, 2018 at 8:20 AM Yu-cheng Yu wrote:
>
> Intel Control-flow Enforcement Technology (CET) introduces the
> following MSRs into the XSAVES system states.
>
> IA32_U_CET (user-mode CET settings),
> IA32_PL3_SSP (user-mode shadow stack),
> IA32_PL0_SSP (kernel-mode shadow sta
Hello,
> Do you have patches that enable usage of ROE in the kernel?
> Alternatively you can write testcases in tools/testing/selftests/kvm to
> test how guests should use it.
As for now ROE isn't integrated yet into the kernel, I did have some
tests I will
have them in selftests/kvm in the next
From: Eddie James
Document the bindings for the FSI-attached POWER9 On-Chip Controller.
Signed-off-by: Eddie James
---
Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt | 16
1 file changed, 16 insertions(+)
create mode 100644 Documentation/devicetree/bindings/fsi/ibm,p9-o
From: Eddie James
Add method to parse the response from the OCC poll command. This only
needs to be done during probe(), since the OCC shouldn't change the
number or format of sensors while it's running. The parsed response
allows quick access to sensor data, as well as information on the
number
From: Eddie James
Setup the sensor attributes for every OCC sensor found by the first poll
response. Register the attributes with hwmon.
Signed-off-by: Eddie James
---
drivers/hwmon/occ/common.c | 337 +
drivers/hwmon/occ/common.h | 16 +++
2 files
From: Eddie James
This series adds a hwmon driver to support the OCC on POWER8 and POWER9
processors. The OCC is an embedded processor that provides realtime power and
thermal monitoring and management.
The series also adds a "bus" driver to handle atomic communication between the
service proces
From: Eddie James
The OCC provides a variety of additional information about the state of
the host processor, such as throttling, error conditions, and the number
of OCCs detected in the system. This information is essential to service
processor applications such as fan control and host managemen
From: Eddie James
Document the hwmon interface for the OCC.
Signed-off-by: Eddie James
---
Documentation/hwmon/occ | 112
1 file changed, 112 insertions(+)
create mode 100644 Documentation/hwmon/occ
diff --git a/Documentation/hwmon/occ b/Docum
From: Eddie James
The OCC is a device embedded on a POWER processor that collects and
aggregates sensor data from the processor and system. The OCC can
provide the raw sensor data as well as perform thermal and power
management on the system.
This driver provides an atomic communications channel
From: Eddie James
Add structures to define all sensor types and versions. Add sysfs show
and store functions for each sensor type. Add a method to construct the
"set user power cap" command and send it to the OCC. Add rate limit to
polling the OCC (in case user-space reads our hwmon entries rapid
From: Eddie James
Document the bindings for I2C-based OCC hwmon device.
Signed-off-by: Eddie James
Acked-by: Rob Herring
---
.../devicetree/bindings/i2c/ibm,p8-occ-hwmon.txt | 25 ++
1 file changed, 25 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i
On Thu, 2018-11-08 at 12:46 -0800, Andy Lutomirski wrote:
> On Thu, Oct 11, 2018 at 8:20 AM Yu-cheng Yu wrote:
> >
> > Intel Control-flow Enforcement Technology (CET) introduces the
> > following MSRs into the XSAVES system states.
> >
> > IA32_U_CET (user-mode CET settings),
> > IA32_PL
From: Eddie James
For the P8 OCC, add the procedure to send a command to the OCC over I2C
bus. This involves writing the OCC command registers with serial
communication operations (SCOMs) interpreted by the I2C slave. For the
P9 OCC, add a procedure to use the OCC in-kernel API to send a command
From: Eddie James
The OCC is a device embedded on a POWER processor that collects and
aggregates sensor data from the processor and system. The OCC can
provide the raw sensor data as well as perform thermal and power
management on the system.
This driver provides a hwmon interface to the OCC fro
On Thu, Nov 8, 2018 at 1:06 PM Yu-cheng Yu wrote:
>
> On Thu, 2018-11-08 at 12:46 -0800, Andy Lutomirski wrote:
> > On Thu, Oct 11, 2018 at 8:20 AM Yu-cheng Yu wrote:
> > >
> > > Intel Control-flow Enforcement Technology (CET) introduces the
> > > following MSRs into the XSAVES system states.
> >
On 11/06/2018 08:20 AM, Matthew Wilcox wrote:
> On Mon, Nov 05, 2018 at 10:43:43AM -0500, Waiman Long wrote:
>> The maximum number of unique System V IPC identifiers was limited to
>> 32k. That limit should be big enough for most use cases.
>>
>> However, there are some users out there requesting
On Thu, Nov 08, 2018 at 01:22:54PM -0800, Andy Lutomirski wrote:
> > >
> > > Why are these __packed? It seems like it'll generate bad code for no
> > > obvious purpose.
> >
> > That prevents any possibility that the compiler will insert padding,
> > although in
> > 64-bit kernel this should not h
On 11/06/2018 08:02 AM, Matthew Wilcox wrote:
> On Mon, Nov 05, 2018 at 10:43:46AM -0500, Waiman Long wrote:
>> The idea of using the cyclic mode to reduce id reuse came from Manfred
>> Spraul . There may be a little bit of
>> additional memory/performance overhead in doing cyclic id allocation,
>>
On 11/8/18 1:22 PM, Andy Lutomirski wrote:
>> +struct cet_kernel_state {
>> + u64 kernel_ssp; /* kernel shadow stack */
>> + u64 pl1_ssp;/* ring-1 shadow stack */
>> + u64 pl2_ssp;/* ring-2 shadow stack */
>> +} __packed;
>> +
> Why are these __packed? It seems like it'll
On Thu, Nov 08, 2018 at 02:01:42PM -0800, Andy Lutomirski wrote:
> > >
> > > They both seem like bugs, perhaps. As I understand it, __packed
> > > removes padding, but it also forces the compiler to expect the fields
> > > to be unaligned even if they are actually aligned.
> >
> > How is that? And
On Thu, Nov 8, 2018 at 1:31 PM Cyrill Gorcunov wrote:
>
> On Thu, Nov 08, 2018 at 01:22:54PM -0800, Andy Lutomirski wrote:
> > > >
> > > > Why are these __packed? It seems like it'll generate bad code for no
> > > > obvious purpose.
> > >
> > > That prevents any possibility that the compiler will
On Thu, Nov 08, 2018 at 01:48:54PM -0800, Dave Hansen wrote:
> On 11/8/18 1:22 PM, Andy Lutomirski wrote:
> >> +struct cet_kernel_state {
> >> + u64 kernel_ssp; /* kernel shadow stack */
> >> + u64 pl1_ssp;/* ring-1 shadow stack */
> >> + u64 pl2_ssp;/* ring-2 shadow stack
On Wednesday, November 7, 2018 11:22:58 PM CET Jonathan Corbet wrote:
> On Fri, 5 Oct 2018 20:51:57 +0200
>
> Federico Vaga wrote:
> > This patch does not translate entirely the subfolder "process/"
> > but only part of it (to begin with).
> >
> > In order to avoid broken links, I included empt
In this small patch set there is the V3 of
"doc:it_IT: add some process/* translations" in which I fixed
the recent conflicts in docs-next.
I took the occasion to add other two simple patches that fix:
- a missing translation in locking.rst
- apply a patch from the official documentation to the ita
Replicate the following patch into italian translation
1bb37a35671c doc-guide:kernel-doc.rst: Reference to foobar
Signed-off-by: Federico Vaga
---
Documentation/translations/it_IT/doc-guide/kernel-doc.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/transla
This title was still in English. I just translated it
Signed-off-by: Federico Vaga
---
Documentation/translations/it_IT/kernel-hacking/locking.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/translations/it_IT/kernel-hacking/locking.rst
b/Documentation/
On 11/8/18 2:00 PM, Matthew Wilcox wrote:
> struct a {
> char c;
> struct b b;
> };
>
> we want struct b to start at offset 8, but with __packed, it will start
> at offset 1.
You're talking about how we want the struct laid out in memory if we
have control over the layout. I'm talkin
On Thu, Nov 08, 2018 at 12:40:02PM -0800, Yu-cheng Yu wrote:
> In fpu_init_system_xstate(), we test and clear features that are not enabled.
> There we depend on the order of these elements. This is the tenth "unknown
> xstate feature".
Aha, those are *reserved* bits - not unused, in XCR0.
Do an
On Thu, Nov 08, 2018 at 03:35:02PM -0800, Dave Hansen wrote:
> On 11/8/18 2:00 PM, Matthew Wilcox wrote:
> > struct a {
> > char c;
> > struct b b;
> > };
> >
> > we want struct b to start at offset 8, but with __packed, it will start
> > at offset 1.
>
> You're talking about how we want
On Thu, Nov 8, 2018 at 4:32 PM Matthew Wilcox wrote:
>
> On Thu, Nov 08, 2018 at 03:35:02PM -0800, Dave Hansen wrote:
> > On 11/8/18 2:00 PM, Matthew Wilcox wrote:
> > > struct a {
> > > char c;
> > > struct b b;
> > > };
> > >
> > > we want struct b to start at offset 8, but with __packed
On Thu, Nov 8, 2018 at 11:28 PM Mark Salyzyn wrote:
>
> On 11/08/2018 12:01 PM, Vivek Goyal wrote:
>
> On Tue, Nov 06, 2018 at 03:01:15PM -0800, Mark Salyzyn wrote:
>
> By default, all access to the upper, lower and work directories is the
> recorded mounter's MAC and DAC credentials. The incomin
On Thu, 8 Nov 2018 19:04:48 +1100
Aleksa Sarai wrote:
> On 2018-11-08, Aleksa Sarai wrote:
> > I will attach what I have at the moment to hopefully explain what the
> > issue I've found is (re-using the kretprobe architecture but with the
> > shadow-stack idea).
>
> Here is the patch I have at
On Thu, 8 Nov 2018 08:44:37 -0600
Josh Poimboeuf wrote:
> On Thu, Nov 08, 2018 at 07:04:48PM +1100, Aleksa Sarai wrote:
> > On 2018-11-08, Aleksa Sarai wrote:
> > > I will attach what I have at the moment to hopefully explain what the
> > > issue I've found is (re-using the kretprobe architectur
82 matches
Mail list logo
