13:12 filter
> -r--r- 1 root root 0 Dec 21 13:12 format
> -r--r- 1 root root 0 Dec 21 13:12 hist
> -r--r- 1 root root 0 Dec 21 13:12 id
> -rw-r- 1 root root 0 Dec 21 13:12 trigger
>
> (b) When the attr does not denote the UID or GID, it defaulted to using
>
e attr does not denote the UID or GID, it defaulted to using
the parent uid or gid. This is incorrect as changing the parent
uid or gid will automatically change all its children.
# chgrp tracing /mnt/events/timer
# ls -ld /mnt/events/timer
drwxr-xr-x 2 root tracing 0 Dec 21 14:34 /m
e attr does not denote the UID or GID, it defaulted to using
the parent uid or gid. This is incorrect as changing the parent
uid or gid will automatically change all its children.
# chgrp tracing /mnt/events/timer
# ls -ld /mnt/events/timer
drwxr-xr-x 2 root tracing 0 Dec 21 14:34 /m
s_attr
> *attr, umode_t mode)
> +static void update_inode_attr(struct dentry *dentry, struct inode *inode,
> + struct eventfs_attr *attr, umode_t mode)
> {
> if (!attr) {
> inode->i_mode = mode;
> @@ -162,9 +163,13 @
>i_mode = mode;
> @@ -162,9 +163,13 @@ static void update_inode_attr(struct inode *inode,
> struct eventfs_attr *attr, um
>
> if (attr->mode & EVENTFS_SAVE_UID)
> inode->i_uid = attr->uid;
> + else
> + inode->i_uid = d_in
mp; EVENTFS_SAVE_UID)
inode->i_uid = attr->uid;
+ else
+ inode->i_uid = d_inode(dentry->d_parent)->i_uid;
if (attr->mode & EVENTFS_SAVE_GID)
inode->i_gid = attr->gid;
+ else
+ inode->i_gid = d_inode(d
On Tue, Apr 20, 2021 at 9:47 AM Christian Brauner
wrote:
>
> If there's no objections then Linus can probably just pick up the single
> patch here directly:
I'm ok with that assuming I don't hear any last-minute concerns..
I'll plan on appling it later today, so anybody with concerns please
holl
On Tue, Apr 20, 2021 at 08:43:34AM -0500, Serge Hallyn wrote:
> cap_setfcap is required to create file capabilities.
>
> Since 8db6c34f1dbc ("Introduce v3 namespaced file capabilities"), a
> process running as uid 0 but without cap_setfcap is able to work around
> this
cap_setfcap is required to create file capabilities.
Since 8db6c34f1dbc ("Introduce v3 namespaced file capabilities"), a
process running as uid 0 but without cap_setfcap is able to work around
this as follows: unshare a new user namespace which maps parent uid 0
into the child namespa
In the parent user namespace all the capabilities are kept
> and AFAIK Docker does the same. I'd expect a change in behavior only
> for nested user namespaces in containers where CAP_SETFCAP is not
> granted, but that is not a common configuration given that CAP_SETFCAP
> is added by
;
> > > Since 8db6c34f1dbc ("Introduce v3 namespaced file capabilities"), a
> > > process running as uid 0 but without cap_setfcap is able to work around
> > > this as follows: unshare a new user namespace which maps parent uid 0
> > > into the child namespace.
On Mon, Apr 19, 2021 at 06:09:11PM +0200, Christian Brauner wrote:
> On Mon, Apr 19, 2021 at 07:25:14AM -0500, Serge Hallyn wrote:
> > cap_setfcap is required to create file capabilities.
> >
> > Since 8db6c34f1dbc ("Introduce v3 namespaced file capabilities"), a
&
On Mon, Apr 19, 2021 at 07:25:14AM -0500, Serge Hallyn wrote:
> cap_setfcap is required to create file capabilities.
>
> Since 8db6c34f1dbc ("Introduce v3 namespaced file capabilities"), a
> process running as uid 0 but without cap_setfcap is able to work around
> this
is added by default.
Same for us and we do have extensive nested container workloads with
other runtimes running containers too.
>
>
> > "Serge E. Hallyn" writes:
> >
> >> +/**
> >> + * verify_root_map() - check the uid 0 mapping
> >> + * @file: idmapping
P is not
granted, but that is not a common configuration given that CAP_SETFCAP
is added by default.
> "Serge E. Hallyn" writes:
>
>> +/**
>> + * verify_root_map() - check the uid 0 mapping
>> + * @file: idmapping file
>> + * @map_ns: user namespace of the t
cap_setfcap is required to create file capabilities.
Since 8db6c34f1dbc ("Introduce v3 namespaced file capabilities"), a
process running as uid 0 but without cap_setfcap is able to work around
this as follows: unshare a new user namespace which maps parent uid 0
into the child namespa
t cause problems as is, I will be
surprised.
Eric
"Serge E. Hallyn" writes:
> A process running as uid 0 but without cap_setfcap currently can simply
> unshare a new user namespace with uid 0 mapped to 0. While this task
> will not have new capabilities against the paren
On Sat, Apr 17, 2021 at 03:04:34PM -0500, Serge Hallyn wrote:
> A process running as uid 0 but without cap_setfcap currently can simply
> unshare a new user namespace with uid 0 mapped to 0. While this task
> will not have new capabilities against the parent namespace, there is
> a
el.org; linux-
> s...@vger.kernel.org
> Subject: Re: [PATCH 1/1] s390/pci: expose a PCI device's UID as its index
>
>
> [EXTERNAL EMAIL]
>
>
>
> On 4/16/21 7:58 PM, K, Narendra wrote:
> >> -Original Message-
> >> From: Niklas Schnelle
> &g
A process running as uid 0 but without cap_setfcap currently can simply
unshare a new user namespace with uid 0 mapped to 0. While this task
will not have new capabilities against the parent namespace, there is
a loophole due to the way namespaced file capabilities work. File
capabilities valid
...@vger.kernel.org; linux-s...@vger.kernel.org
Subject: Re: [PATCH 1/1] s390/pci: expose a PCI device's UID as its index
[EXTERNAL EMAIL]
On Wed, 2021-04-14 at 15:17 -0500, Bjorn Helgaas wrote:
On Mon, Apr 12, 2021 at 03:59:05PM +0200, Niklas Schnelle wrote:
On s390 each PCI device has a
ch.
> > > v4 is at
> > > https://git.kernel.org/pub/scm/linux/kernel/git/sergeh/linux.git/log/?h=2021-04-15/setfcap-nsfscaps-v4
> > > and is the approach you suggested. I can send it also as a separate patch
> > > if you like)
> > >
> > >
rgeh/linux.git/log/?h=2021-04-15/setfcap-nsfscaps-v4
> > and is the approach you suggested. I can send it also as a separate patch
> > if you like)
> >
> > A process running as uid 0 but without cap_setfcap currently can simply
> > unshare a new user namespace with ui
r.kernel.org; linux-s...@vger.kernel.org
> Subject: Re: [PATCH 1/1] s390/pci: expose a PCI device's UID as its index
>
>
> [EXTERNAL EMAIL]
>
> On Wed, 2021-04-14 at 15:17 -0500, Bjorn Helgaas wrote:
> > On Mon, Apr 12, 2021 at 03:59:05PM +0200, Niklas Schnelle wrote:
> &
sted. I can send it also as a separate patch
> if you like)
>
> A process running as uid 0 but without cap_setfcap currently can simply
> unshare a new user namespace with uid 0 mapped to 0. While this task
> will not have new capabilities against the parent namespace, there is
uid 0 but without cap_setfcap currently can simply
unshare a new user namespace with uid 0 mapped to 0. While this task
will not have new capabilities against the parent namespace, there is
a loophole due to the way namespaced file capabilities work. File
capabilities valid in userns 1 are
On Wed, 2021-04-14 at 15:17 -0500, Bjorn Helgaas wrote:
> On Mon, Apr 12, 2021 at 03:59:05PM +0200, Niklas Schnelle wrote:
> > On s390 each PCI device has a user-defined ID (UID) exposed under
> > /sys/bus/pci/devices//uid. This ID was designed to serve as the PCI
> > device&#
On Mon, Apr 12, 2021 at 03:59:05PM +0200, Niklas Schnelle wrote:
> On s390 each PCI device has a user-defined ID (UID) exposed under
> /sys/bus/pci/devices//uid. This ID was designed to serve as the PCI
> device's primary index and to match the device within Linux to the
> device
On s390 each PCI device has a user-defined ID (UID) exposed under
/sys/bus/pci/devices//uid. This ID was designed to serve as the PCI
device's primary index and to match the device within Linux to the
device configured in the hypervisor. To serve as a primary identifier
the UID must be u
From: Will Deacon
We can advertise ourselves to guests as KVM and provide a basic features
bitmap for discoverability of future hypervisor services.
Cc: Marc Zyngier
Signed-off-by: Will Deacon
Signed-off-by: Jianyong Wu
Signed-off-by: Marc Zyngier
Link: https://lore.kernel.org/r/202012090609
On s390 each PCI device has a user-defined ID (UID) exposed under
/sys/bus/pci/devices//uid. This ID was designed to serve as the PCI
device's primary index and to match the device within Linux to the
device configured in the hypervisor. To serve as a primary identifier
the UID must be u
));
+ u32 index = ~0;
+
+ if (zpci_unique_uid)
+ index = zdev->uid;
+
+ return sprintf(buf, "%u\n", index);
[...]
Would it be possible to use the new sysfs_emit() rather than sprintf()
even though the zpci_attr macro and still use mio_enabled_show() still
woul
t; +u32 index = ~0;
>> +
>> +if (zpci_unique_uid)
>> +index = zdev->uid;
>> +
>> +return sprintf(buf, "%u\n", index);
> [...]
>
> Would it be possible to use the new sysfs_emit() rather than sprintf()
> even though the zp
Hi Niklas,
[...]
> +static ssize_t index_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct zpci_dev *zdev = to_zpci(to_pci_dev(dev));
> + u32 index = ~0;
> +
> + if (zpci_unique_uid)
> +
Hi,
On s390 each PCI device has a user-defined ID (UID). This ID was
designed to serve as the PCI device's primary index and to match the
device within Linux to the with the view in the hypervisor
configuration. To serve as a primary identifier the UID must be unique
within the Linux ins
On s390 each PCI device has a user-defined ID (UID) exposed under
/sys/bus/pci/devices//uid. This ID was designed to serve as the PCI
device's primary index and to match the device within Linux to the
device configured in the hypervisor. To serve as a primary identifier
the UID must be u
From: Will Deacon
We can advertise ourselves to guests as KVM and provide a basic features
bitmap for discoverability of future hypervisor services.
Signed-off-by: Will Deacon
Signed-off-by: Gavin Shan
---
arch/arm64/kvm/hypercalls.c | 27 ++-
1 file changed, 18 insert
From: Will Deacon
We can advertise ourselves to guests as KVM and provide a basic features
bitmap for discoverability of future hypervisor services.
Cc: Marc Zyngier
Signed-off-by: Will Deacon
Signed-off-by: Jianyong Wu
Signed-off-by: Marc Zyngier
Link: https://lore.kernel.org/r/202012090609
On 2/4/21 2:38 PM, Greg Kroah-Hartman wrote:
> On Thu, Feb 04, 2021 at 01:02:51PM +0100, Niklas Schnelle wrote:
>>
>>
>> On 2/4/21 11:40 AM, Greg Kroah-Hartman wrote:
>>> On Thu, Feb 04, 2021 at 10:43:53AM +0100, Niklas Schnelle wrote:
>>>> The globa
On Thu, Feb 04, 2021 at 01:02:51PM +0100, Niklas Schnelle wrote:
>
>
> On 2/4/21 11:40 AM, Greg Kroah-Hartman wrote:
> > On Thu, Feb 04, 2021 at 10:43:53AM +0100, Niklas Schnelle wrote:
> >> The global UID uniqueness attribute exposes whether the platform
> >>
On 2/4/21 11:40 AM, Greg Kroah-Hartman wrote:
> On Thu, Feb 04, 2021 at 10:43:53AM +0100, Niklas Schnelle wrote:
>> The global UID uniqueness attribute exposes whether the platform
>> guarantees that the user-defined per-device UID attribute values
>> (/sys/bus/pci/device
On Thu, Feb 04, 2021 at 10:43:53AM +0100, Niklas Schnelle wrote:
> The global UID uniqueness attribute exposes whether the platform
> guarantees that the user-defined per-device UID attribute values
> (/sys/bus/pci/device//uid) are unique and can thus be used as
> a global identi
The global UID uniqueness attribute exposes whether the platform
guarantees that the user-defined per-device UID attribute values
(/sys/bus/pci/device//uid) are unique and can thus be used as
a global identifier for the associated PCI device. With this commit
it is exposed at /sys/bus/pci/zpci
Hi Bjorn,
this is a follow-up to my previous RFC of exposing our s390 specific UID
Checking attribute at /sys/bus/pci/zpci/unique_uids. As suggested by Greg
(thanks!) this version changes things to use named attributes directly without
resorting to any raw kobject handling, as a result the code
From: Will Deacon
We can advertise ourselves to guests as KVM and provide a basic features
bitmap for discoverability of future hypervisor services.
Cc: Marc Zyngier
Signed-off-by: Will Deacon
Signed-off-by: Jianyong Wu
Signed-off-by: Marc Zyngier
Link: https://lore.kernel.org/r/202012090609
> > Currently a non-root process can create directories, but cannot
> > create stuff in the directories it creates.
>
> Isn't that on purpose?
Is it? What's the use case of being able to create empty directories
you can't use?
Why allow their creation in the first place then?
> > + (
On Sat, Jan 23, 2021 at 12:55:16PM -0800, Maciej Żenczykowski wrote:
> From: Maciej Żenczykowski
>
> Currently a non-root process can create directories, but cannot
> create stuff in the directories it creates.
Isn't that on purpose?
>
> Example (before this patch):
&
On 2021-01-25 14:25:38, Miklos Szeredi wrote:
> On Fri, Jan 22, 2021 at 7:31 PM Tyler Hicks wrote:
> >
> > On 2021-01-19 17:22:03, Miklos Szeredi wrote:
> > > Prior to commit 7c03e2cda4a5 ("vfs: move cap_convert_nscap() call into
> > > vfs_setxattr()") the translation of nscap->rootid did not take
fy that the bug exists after
> > 7c03e2cda4a5 and then again to verify that this patch fixes the bug?
>
> You need two terminals:
> $ =
> # = root
>
> $ unshare -Um
> $ echo $$
>
> # echo "0 1000 1" > uid_map
NOTE: is assumed to have uid=1000, so this and following
"1000" values need to be fixed up if it's not the case.
Thanks,
Miklos
On Fri, Jan 22, 2021 at 7:31 PM Tyler Hicks wrote:
>
> On 2021-01-19 17:22:03, Miklos Szeredi wrote:
> > Prior to commit 7c03e2cda4a5 ("vfs: move cap_convert_nscap() call into
> > vfs_setxattr()") the translation of nscap->rootid did not take stacked
> > filesystems (overlayfs and ecryptfs) into a
From: Maciej Żenczykowski
Currently a non-root process can create directories, but cannot
create stuff in the directories it creates.
Example (before this patch):
phone:/ $ id
uid=1000(system) gid=1000(system) groups=1000(system),... context=u:r:su:s0
phone:/ $ cd /config/usb_gadget/g1
On 2021-01-19 17:22:03, Miklos Szeredi wrote:
> Prior to commit 7c03e2cda4a5 ("vfs: move cap_convert_nscap() call into
> vfs_setxattr()") the translation of nscap->rootid did not take stacked
> filesystems (overlayfs and ecryptfs) into account.
>
> That patch fixed the overlay case, but made the e
On 2021-01-20 08:52:27, Miklos Szeredi wrote:
> On Tue, Jan 19, 2021 at 10:11 PM Eric W. Biederman
> wrote:
> >
> > Miklos Szeredi writes:
> >
> > > Prior to commit 7c03e2cda4a5 ("vfs: move cap_convert_nscap() call into
> > > vfs_setxattr()") the translation of nscap->rootid did not take stacked
On 1/21/21 6:28 PM, Greg Kroah-Hartman wrote:
> On Thu, Jan 21, 2021 at 06:04:52PM +0100, Niklas Schnelle wrote:
>>
>>
>> On 1/21/21 4:54 PM, Bjorn Helgaas wrote:
>>> [Greg may be able to help compare/contrast this s390 UID with udev
>>> persistent names
On Thu, Jan 21, 2021 at 06:04:52PM +0100, Niklas Schnelle wrote:
>
>
> On 1/21/21 4:54 PM, Bjorn Helgaas wrote:
> > [Greg may be able to help compare/contrast this s390 UID with udev
> > persistent names]
> >
> > On Thu, Jan 21, 2021 at 04:31:55PM +0100, Niklas
On 1/21/21 4:54 PM, Bjorn Helgaas wrote:
> [Greg may be able to help compare/contrast this s390 UID with udev
> persistent names]
>
> On Thu, Jan 21, 2021 at 04:31:55PM +0100, Niklas Schnelle wrote:
>> On 1/15/21 4:29 PM, Bjorn Helgaas wrote:
>>> On Fri, Jan 1
[Greg may be able to help compare/contrast this s390 UID with udev
persistent names]
On Thu, Jan 21, 2021 at 04:31:55PM +0100, Niklas Schnelle wrote:
> On 1/15/21 4:29 PM, Bjorn Helgaas wrote:
> > On Fri, Jan 15, 2021 at 12:20:59PM +0100, Niklas Schnelle wrote:
> >> On 1/14/21 5
On Thu, Jan 21, 2021 at 09:54:45AM -0600, Bjorn Helgaas wrote:
> [Greg may be able to help compare/contrast this s390 UID with udev
> persistent names]
>
> On Thu, Jan 21, 2021 at 04:31:55PM +0100, Niklas Schnelle wrote:
> > On 1/15/21 4:29 PM, Bjorn Helgaas wrote:
> > &
; too.
>>
>> That said, I think we could also add something like
>> bus_create_group(). Then we could use that to also clean up
>> drivers/pci/slot.c:pci_slot_init() and get the original path
>> /sys/bus/pci/zpci/uid_checking.
>
> I don't think "uid_checking&q
On Tue, Jan 19, 2021 at 10:11 PM Eric W. Biederman
wrote:
>
> Miklos Szeredi writes:
>
> > Prior to commit 7c03e2cda4a5 ("vfs: move cap_convert_nscap() call into
> > vfs_setxattr()") the translation of nscap->rootid did not take stacked
> > filesystems (overlayfs and ecryptfs) into account.
> >
>
Miklos Szeredi writes:
> Prior to commit 7c03e2cda4a5 ("vfs: move cap_convert_nscap() call into
> vfs_setxattr()") the translation of nscap->rootid did not take stacked
> filesystems (overlayfs and ecryptfs) into account.
>
> That patch fixed the overlay case, but made the ecryptfs case worse.
>
Prior to commit 7c03e2cda4a5 ("vfs: move cap_convert_nscap() call into
vfs_setxattr()") the translation of nscap->rootid did not take stacked
filesystems (overlayfs and ecryptfs) into account.
That patch fixed the overlay case, but made the ecryptfs case worse.
Restore old the behavior for ecrypt
above again, with a simple attribute group, and name for it, and
>>> it should "just work".
>>
>> I'm probably missing something but I don't get how this could work
>> in this case. If I'm seeing this right the default attribute group
>> he
j,
> >> &zpci_attr_group_global);
> >
> > Huge hint, if in a driver, or bus subsystem, and you call sysfs_*,
> > that's usually a huge clue that you are doing something wrong.
> >
> > Try the above again, with a simple attribute group, and name
On Fri, Jan 15, 2021 at 12:20:59PM +0100, Niklas Schnelle wrote:
>
>
> On 1/14/21 5:14 PM, Greg Kroah-Hartman wrote:
> > On Thu, Jan 14, 2021 at 04:51:17PM +0100, Niklas Schnelle wrote:
> >>
> >>
> >> On 1/14/21 4:17 PM, Greg Kroah-Hartman wrote:
> >>> On Thu, Jan 14, 2021 at 04:06:11PM +0100, Ni
On 1/14/21 5:14 PM, Greg Kroah-Hartman wrote:
> On Thu, Jan 14, 2021 at 04:51:17PM +0100, Niklas Schnelle wrote:
>>
>>
>> On 1/14/21 4:17 PM, Greg Kroah-Hartman wrote:
>>> On Thu, Jan 14, 2021 at 04:06:11PM +0100, Niklas Schnelle wrote:
On 1/14/21 2:58 PM, Greg Kroah-Hartman wrote
;>>> On Wed, Jan 13, 2021 at 08:47:58AM +0100, Niklas Schnelle wrote:
> >>>>>>> On 1/12/21 10:50 PM, Bjorn Helgaas wrote:
> >>>>>>>> On Mon, Jan 11, 2021 at 10:38:57AM +0100, Niklas Schnelle wrote:
> >>>>
, Jan 14, 2021 at 02:20:10PM +0100, Niklas Schnelle wrote:
>>>>>
>>>>>
>>>>> On 1/13/21 7:55 PM, Bjorn Helgaas wrote:
>>>>>> On Wed, Jan 13, 2021 at 08:47:58AM +0100, Niklas Schnelle wrote:
>>>>>>> On 1/12/21 10:50 PM
;>
> >>>
> >>> On 1/13/21 7:55 PM, Bjorn Helgaas wrote:
> >>>> On Wed, Jan 13, 2021 at 08:47:58AM +0100, Niklas Schnelle wrote:
> >>>>> On 1/12/21 10:50 PM, Bjorn Helgaas wrote:
> >>>>>> On Mon, Jan 11, 2021 at 10:38
On Wed, Jan 13, 2021 at 08:47:58AM +0100, Niklas Schnelle wrote:
>>>>> On 1/12/21 10:50 PM, Bjorn Helgaas wrote:
>>>>>> On Mon, Jan 11, 2021 at 10:38:57AM +0100, Niklas Schnelle wrote:
>>>>>>> We use the UID of a zPCI adapter, or the UID of the functio
; > >> On 1/12/21 10:50 PM, Bjorn Helgaas wrote:
> > >>> On Mon, Jan 11, 2021 at 10:38:57AM +0100, Niklas Schnelle wrote:
> > >>>> We use the UID of a zPCI adapter, or the UID of the function zero if
> > >>>> there are multiple funct
at 10:38:57AM +0100, Niklas Schnelle wrote:
> >>>> We use the UID of a zPCI adapter, or the UID of the function zero if
> >>>> there are multiple functions in an adapter, as PCI domain if and only if
> >>>> UID Checking is turned on.
> >>>&g
On 1/13/21 7:55 PM, Bjorn Helgaas wrote:
> On Wed, Jan 13, 2021 at 08:47:58AM +0100, Niklas Schnelle wrote:
>> On 1/12/21 10:50 PM, Bjorn Helgaas wrote:
>>> On Mon, Jan 11, 2021 at 10:38:57AM +0100, Niklas Schnelle wrote:
>>>> We use the UID of a zPCI adapter, or t
On Wed, Jan 13, 2021 at 08:47:58AM +0100, Niklas Schnelle wrote:
> On 1/12/21 10:50 PM, Bjorn Helgaas wrote:
> > On Mon, Jan 11, 2021 at 10:38:57AM +0100, Niklas Schnelle wrote:
> >> We use the UID of a zPCI adapter, or the UID of the function zero if
> >> there a
On 1/12/21 10:50 PM, Bjorn Helgaas wrote:
> On Mon, Jan 11, 2021 at 10:38:57AM +0100, Niklas Schnelle wrote:
>> We use the UID of a zPCI adapter, or the UID of the function zero if
>> there are multiple functions in an adapter, as PCI domain if and only if
>> UID
On Mon, Jan 11, 2021 at 10:38:57AM +0100, Niklas Schnelle wrote:
> We use the UID of a zPCI adapter, or the UID of the function zero if
> there are multiple functions in an adapter, as PCI domain if and only if
> UID Checking is turned on.
> Otherwise we automatically generate domain
Hi Bjorn, Hi Kernel Hackers,
With the below patch I'm proposing to expose a global (i.e. not device
bound) runtime attribute of the s390 PCI implementation (zPCI) called
"UID Checking". You can find some background information on what this
attribute means and why it is importan
We use the UID of a zPCI adapter, or the UID of the function zero if
there are multiple functions in an adapter, as PCI domain if and only if
UID Checking is turned on.
Otherwise we automatically generate domains as devices appear.
The state of UID Checking is thus essential to know if the PCI
From: Will Deacon
We can advertise ourselves to guests as KVM and provide a basic features
bitmap for discoverability of future hypervisor services.
Cc: Marc Zyngier
Signed-off-by: Will Deacon
Signed-off-by: Jianyong Wu
---
arch/arm64/kvm/hypercalls.c | 27 ++-
1 file
From: Will Deacon
We can advertise ourselves to guests as KVM and provide a basic features
bitmap for discoverability of future hypervisor services.
Cc: Marc Zyngier
Signed-off-by: Will Deacon
Signed-off-by: Jianyong Wu
---
arch/arm64/kvm/hypercalls.c | 27 ++-
1 file
From: Will Deacon
We can advertise ourselves to guests as KVM and provide a basic features
bitmap for discoverability of future hypervisor services.
Cc: Marc Zyngier
Signed-off-by: Will Deacon
Signed-off-by: Jianyong Wu
---
arch/arm64/kvm/hypercalls.c | 29 +++--
1 fi
cs.columbia.edu;
> > k...@vger.kernel.org; Steve Capper ; Kaly Xin
> > ; Justin He ; Wei Chen
> > ; nd
> > Subject: Re: [PATCH v13 2/9] arm/arm64: KVM: Advertise KVM UID to guests
> > via SMCCC
> >
> > On Mon, Jul 27, 2020 at 03:45:37AM +, Jianyong Wu wrote
From: Krzysztof Struczynski
Add function that checks if the UID map is defined. It will be used by
ima to check if ID remapping in subject-based rules is necessary.
Signed-off-by: Krzysztof Struczynski
---
include/linux/user_namespace.h | 6 ++
kernel/user_namespace.c| 11
TCH v13 2/9] arm/arm64: KVM: Advertise KVM UID to guests
> via SMCCC
>
> On Mon, Jul 27, 2020 at 03:45:37AM +, Jianyong Wu wrote:
> > > From: Will Deacon
> > >
> > > We can advertise ourselves to guests as KVM and provide a basic
> > > features
7;re right that this is a bug, but isn't the solution just
to make that an array of 'long'?
long val [4];
That will sign-extend the negative error codes as required, while leaving
the explicitly unsigned UID constants alone.
Will
d
> Subject: [PATCH v13 2/9] arm/arm64: KVM: Advertise KVM UID to guests via
> SMCCC
>
> From: Will Deacon
>
> We can advertise ourselves to guests as KVM and provide a basic features
> bitmap for discoverability of future hypervisor services.
>
> Cc: Marc Z
Replace the uid/gid/perm permissions checking on a key with an ACL to allow
the SETATTR and SEARCH permissions to be split. This will also allow a
greater range of subjects to represented.
Define a KEYCTL_CAPS_ACL capabilities bit to indicate if the kernel has
this change applied
From: Anson Huang
[ Upstream commit c95c9693b112f312b59c5d100fd09a1349970fab ]
Correct i.MX8MP UID fuse offset according to fuse map:
UID_LOW: 0x420
UID_HIGH: 0x430
Fixes: fc40200ebf82 ("soc: imx: increase build coverage for imx8m soc driver")
Fixes: 18f662a73862 ("soc: imx:
On Wed, Jun 10, 2020 at 06:03:02PM +0800, Anson Huang wrote:
> Correct i.MX8MP UID fuse offset according to fuse map:
>
> UID_LOW: 0x420
> UID_HIGH: 0x430
>
> Fixes: fc40200ebf82 ("soc: imx: increase build coverage for imx8m soc driver")
> Fixes: 18f662a73862 (&q
From: Will Deacon
We can advertise ourselves to guests as KVM and provide a basic features
bitmap for discoverability of future hypervisor services.
Cc: Marc Zyngier
Signed-off-by: Will Deacon
Signed-off-by: Jianyong Wu
---
arch/arm64/kvm/hypercalls.c | 29 +++--
1 fi
From: Will Deacon
We can advertise ourselves to guests as KVM and provide a basic features
bitmap for discoverability of future hypervisor services.
Cc: Marc Zyngier
Signed-off-by: Will Deacon
Signed-off-by: Jianyong Wu
---
arch/arm64/kvm/hypercalls.c | 29 +++--
1 fi
On 6/10/2020 1:03 PM, Anson Huang wrote:
Correct i.MX8MP UID fuse offset according to fuse map:
UID_LOW: 0x420
UID_HIGH: 0x430
Fixes: fc40200ebf82 ("soc: imx: increase build coverage for imx8m soc driver")
Fixes: 18f662a73862 ("soc: imx: Add i.MX8MP SoC driver support")
Correct i.MX8MP UID fuse offset according to fuse map:
UID_LOW: 0x420
UID_HIGH: 0x430
Fixes: fc40200ebf82 ("soc: imx: increase build coverage for imx8m soc driver")
Fixes: 18f662a73862 ("soc: imx: Add i.MX8MP SoC driver support")
Signed-off-by: Anson Huang
---
Changes sin
Hi, Luliana
> Subject: Re: [PATCH V2] soc: imx8m: Correct i.MX8MP UID fuse offset
>
>
>
> On 6/10/2020 10:57 AM, Anson Huang wrote:
> >
> >> Subject: RE: [PATCH V2] soc: imx8m: Correct i.MX8MP UID fuse offset
> >>
> >>> From: Anson
On 6/10/2020 10:57 AM, Anson Huang wrote:
Subject: RE: [PATCH V2] soc: imx8m: Correct i.MX8MP UID fuse offset
From: Anson Huang
Sent: Wednesday, June 10, 2020 6:42 AM
Correct i.MX8MP UID fuse offset according to fuse map:
UID_LOW: 0x420
UID_HIGH: 0x430
Fixes: fc40200ebf82 ("soc
> Subject: RE: [PATCH V2] soc: imx8m: Correct i.MX8MP UID fuse offset
>
> > From: Anson Huang
> > Sent: Wednesday, June 10, 2020 6:42 AM
> >
> > Correct i.MX8MP UID fuse offset according to fuse map:
> >
> > UID_LOW: 0x420
> > UID_HIGH: 0x430
> From: Anson Huang
> Sent: Wednesday, June 10, 2020 6:42 AM
>
> Correct i.MX8MP UID fuse offset according to fuse map:
>
> UID_LOW: 0x420
> UID_HIGH: 0x430
>
> Fixes: fc40200ebf82 ("soc: imx: increase build coverage for imx8m soc driver")
AFAIK "
Correct i.MX8MP UID fuse offset according to fuse map:
UID_LOW: 0x420
UID_HIGH: 0x430
Fixes: fc40200ebf82 ("soc: imx: increase build coverage for imx8m soc driver")
Signed-off-by: Anson Huang
---
Changes since V1:
- add fix tag.
---
drivers/soc/imx/soc-imx8m.c | 8 ++
Hi, Luliana
> Subject: RE: [PATCH] soc: imx8m: Correct i.MX8MP UID fuse offset
>
> Hi, Luliana
>
>
> > Subject: Re: [PATCH] soc: imx8m: Correct i.MX8MP UID fuse offset
> >
> >
> >
> > On 6/9/2020 4:15 PM, Anson Huang wrote:
> > >
Hi, Luliana
> Subject: Re: [PATCH] soc: imx8m: Correct i.MX8MP UID fuse offset
>
>
>
> On 6/9/2020 4:15 PM, Anson Huang wrote:
> > Correct i.MX8MP UID fuse offset according to fuse map:
> >
> > UID_LOW: 0x420
> > UID_HIGH: 0x430
> >
> > Sign
1 - 100 of 644 matches
Mail list logo
