Hi Vivek,
On 1/21/21 6:34 PM, Vivek Kumar Gautam wrote:
> Hi Eric,
>
>
> On 1/19/21 2:33 PM, Auger Eric wrote:
>> Hi Vivek,
>>
>> On 1/15/21 1:13 PM, Vivek Gautam wrote:
>>> This patch-series aims at enabling Nested stage translation in guests
>>>
oducer: https://syzkaller.appspot.com/x/repro.c?x=13856bc750
> >
> > The issue was bisected to:
> >
> > commit 3226b158e67cfaa677fd180152bfb28989cb2fac
> > Author: Eric Dumazet
> > Date: Wed Jan 13 16:18:19 2021 +
> >
> > net: avoid 32 x t
rto_to_user_timeout()
> helper to improve accuracy").
>
> Signed-off-by: Enke Chen
> Reviewed-by: Neal Cardwell
> ---
SGTM, thanks !
Signed-off-by: Eric Dumazet
mokx into the blacklist keyring during boot.
Signed-off-by: Eric Snowberg
Suggested-by: James Bottomley
---
security/integrity/platform_certs/load_uefi.c | 20 +--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/security/integrity/platform_certs/load_uefi.c
b
in the .blacklist keyring
are referenced, if a matching key is found, the key will be rejected.
Signed-off-by: Eric Snowberg
Reviewed-by: Jarkko Sakkinen
Signed-off-by: David Howells
---
v5: Function name changes done by David Howells
---
certs/blacklist.c | 32
]
https://patchwork.kernel.org/project/linux-security-module/patch/20200916004927.64276-1-eric.snowb...@oracle.com/
[2] https://lore.kernel.org/patchwork/cover/1315485/
Eric Snowberg (4):
certs: Add EFI_CERT_X509_GUID support for dbx entries
certs: Move load_system_certificate_list to a common
Add a new Kconfig option called SYSTEM_REVOCATION_KEYS. If set,
this option should be the filename of a PEM-formated file containing
X.509 certificates to be included in the default blacklist keyring.
Signed-off-by: Eric Snowberg
Acked-by: Jarkko Sakkinen
---
certs/Kconfig
Move functionality within load_system_certificate_list to a common
function, so it can be reused in the future.
Signed-off-by: Eric Snowberg
Acked-by: Jarkko Sakkinen
---
certs/Makefile | 2 +-
certs/common.c | 56 ++
certs/common.h
Alexey Gladkov writes:
> On Tue, Jan 19, 2021 at 07:57:36PM -0600, Eric W. Biederman wrote:
>> Alexey Gladkov writes:
>>
>> > On Mon, Jan 18, 2021 at 12:34:29PM -0800, Linus Torvalds wrote:
>> >> On Mon, Jan 18, 2021 at 11:46 AM Alexey Gladkov
>> >
pace by having no_new_privs enforce
progressinvely tighter permissions.
Fixes: 9fcf78cca198 ("apparmor: update domain transitions that are subsets of
confinement at nnp")
Signed-off-by: Eric W. Biederman
---
I came accross this while examining the places cred_guard_mutex is
used and tryi
TL;DR selinux and apparmor ignore no_new_privs
What?
John Johansen writes:
> On 1/20/21 1:26 PM, Eric W. Biederman wrote:
>>
>> The current understanding of apparmor with respect to no_new_privs is at
>> odds with how no_new_privs is implemented and unde
> On Jan 20, 2021, at 4:26 AM, Jarkko Sakkinen wrote:
>
> On Fri, Jan 15, 2021 at 09:49:02AM -0700, Eric Snowberg wrote:
>>
>>> On Jan 15, 2021, at 2:15 AM, Jarkko Sakkinen wrote:
>>>
>>> On Wed, Jan 13, 2021 at 05:11:10PM -0700, Eric Snowberg wrot
This should now Cc the correct email address for James Morris.
ebied...@xmission.com (Eric W. Biederman) writes:
> The current understanding of apparmor with respect to no_new_privs is at
> odds with how no_new_privs is implemented and understood by the rest of
> the kernel
On Wed, 20 Jan 2021 at 13:02, Eric Curtin wrote:
>
> The current default value for max_user_watches is the 1/16 (6.25%) of
> the available low memory, divided for the "watch" cost in bytes.
>
> Tools like inotify-tools and visual studio code, seem to hit these
value for this.
Signed-off-by: Eric Curtin
---
Documentation/admin-guide/sysctl/fs.rst | 4 ++--
fs/eventpoll.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/admin-guide/sysctl/fs.rst
b/Documentation/admin-guide/sysctl/fs
max_user_watches for epoll should say 1/25, rather than 1/32
Signed-off-by: Eric Curtin
---
Documentation/admin-guide/sysctl/fs.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/sysctl/fs.rst
b/Documentation/admin-guide/sysctl/fs.rst
index
his kind of issue does not happen for IPv6. This is
> > because tcp_v6_syn_recv_sock() clones both ipv6_opt and pktopts which
> > correspond to ireq_opt in IPv4.
> >
> > Fixes: 01770a166165 ("tcp: fix race condition when creating child sockets
> > from syncookies")
> > CC: Ricardo Dias
> > Signed-off-by: Kuniyuki Iwashima
> > Reviewed-by: Benjamin Herrenschmidt
>
> Ricardo, Eric, any reason this was written this way?
Well, I guess that was a plain bug.
IPv4 options are not used often I think.
Reviewed-by: Eric Dumazet
Hi Alex,
On 1/19/21 11:45 PM, Alex Williamson wrote:
> On Fri, 15 Jan 2021 10:24:33 +0100
> Auger Eric wrote:
>
>> Hi Vikas,
>> On 1/15/21 7:35 AM, Vikas Gupta wrote:
>>> Hi Eric,
>>>
>>> On Tue, Jan 12, 2021 at 2:52 PM Auger Eric wrote:
&
se it was renamed from
CRYPTO_BLKCIPHER in 5.5. If this patch is really important enough to backport,
CRYPTO_SKCIPHER will need to be changed to CRYPTO_BLKCIPHER.
- Eric
ebied...@xmission.com (Eric W. Biederman) writes:
> Alexey Gladkov writes:
>
>> On Mon, Jan 18, 2021 at 12:34:29PM -0800, Linus Torvalds wrote:
>>> On Mon, Jan 18, 2021 at 11:46 AM Alexey Gladkov
>>> wrote:
>>> >
>>> > Sorry about that.
eems nice. Perhaps
the path forward would be to start with stupid/correct code that always
takes the ucounts_lock for every increment of ucounts->count, that is
later replaced with something more optimal.
Not impacting performance in the non-namespace cases and having good
performance in the other cases is a fundamental requirement of merging
code like this.
Eric
this works with stacking. In particular
ovl_xattr_set appears to call vfs_getxattr without overriding the creds.
What the purpose of that is I haven't quite figured out. It looks like
it is just a probe to see if an xattr is present so maybe it is ok.
Acked-by: "Eric W. Bieder
a different userns
thatn curent_user_ns for the overlay filesystem and that would break
this.
So while I agree with the making a minimal fix for now. We need a good
fix because this code is much too subtle, and it can break very easily
with no one noticing.
Eric
> Thanks,
> Miklos
delegated_inode and breaking
leases. Code that is enabled with CONFIG_FILE_LOCKING. So unless
I am missing something this introduces a different regression into
ecryptfs.
>
> Reported-by: Eric W. Biederman
> Cc: Tyler Hicks
> Fixes: 7c03e2cda4a5 ("vfs: move cap_convert
Comment did not match function signature.
Signed-off-by: Eric Curtin
---
drivers/scsi/lpfc/lpfc_mbox.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/lpfc/lpfc_mbox.c b/drivers/scsi/lpfc/lpfc_mbox.c
index 3414ffcb26fe..c03a7f12dd65 100644
--- a/drivers/scsi
t virtio backend
> and support in VMM.
>
> For testing we have added necessary support in kvmtool. The changes in
> kvmtool are based on virtio-iommu development branch by Jean-Philippe
> Brucker [3].
>
> The tested kernel branch contains following in the order bottom to top
>
CLMULQDQ and not AES-NI. In general, we've tried to
> implement x86 CPU features independently, even if they never show up in
> a real CPU independently.
We only add optimized implementations of crypto algorithms if they are actually
useful, though. If they would never be used in practice, that's not useful.
- Eric
case for authentication only.
>
> Although I am not sure if GHASH is specifically used for this or SHA?
>
> Also, I do not know of any cores that implement PCLMULQDQ and not AES-NI.
>
dm-verity only uses unkeyed hash algorithms. So no, it doesn't use GHASH.
- Eric
> On Jan 15, 2021, at 10:21 AM, James Bottomley
> wrote:
>
> On Tue, 2020-09-15 at 20:49 -0400, Eric Snowberg wrote:
>> The Secure Boot Forbidden Signature Database, dbx, contains a list of
>> now revoked signatures and keys previously approved to boot with UEFI
>
> On Jan 15, 2021, at 2:15 AM, Jarkko Sakkinen wrote:
>
> On Wed, Jan 13, 2021 at 05:11:10PM -0700, Eric Snowberg wrote:
>>
>>> On Jan 13, 2021, at 1:41 PM, Jarkko Sakkinen
>>> wrote:
>>>
>>> On Tue, Jan 12, 2021 at 02:57:39PM +0
On Fri, Jan 15, 2021 at 12:55 AM Alexander Lobakin wrote:
>
> Commit 3226b158e67c ("net: avoid 32 x truesize under-estimation for
> tiny skbs") ensured that skbs with data size lower than 1025 bytes
> will be kmalloc'ed to avoid excessive page cache fragmentation and
> memory consumption.
> Howeve
is too late to filter.
>
> Eric, thoughts?
Exactly, this is what happens.
I do not know how tcpdump and other programs deal with this.
Maybe by setting a small buffer size, or draining the queue.
>
> On Wed, Jan 6, 2021 at 6:55 AM Tom Cook wrote:
> >
> > Another factoid
Hi Vikas,
On 1/15/21 7:26 AM, Vikas Gupta wrote:
> Hi Eric,
>
> On Tue, Jan 12, 2021 at 2:30 PM Auger Eric wrote:
>>
>> Hi Vikas,
>>
>> On 1/5/21 6:53 AM, Vikas Gupta wrote:
>>> On Tue, Dec 22, 2020 at 10:57 PM Auger Eric wrote:
>>>>
>
Hi Vikas,
On 1/15/21 7:35 AM, Vikas Gupta wrote:
> Hi Eric,
>
> On Tue, Jan 12, 2021 at 2:52 PM Auger Eric wrote:
>>
>> Hi Vikas,
>>
>> On 12/14/20 6:45 PM, Vikas Gupta wrote:
>>> Add msi support for Broadcom platform devices
>>>
>>> Si
Hi Jean,
On 1/14/21 6:33 PM, Jean-Philippe Brucker wrote:
> Hi Eric,
>
> On Thu, Jan 14, 2021 at 05:58:27PM +0100, Auger Eric wrote:
>>>> The uacce-devel branches from
>>>>> https://github.com/Linaro/linux-kernel-uadk do provide this at the moment
>&g
Hi Shameer, Jean-Philippe,
On 12/4/20 11:23 AM, Auger Eric wrote:
> Hi Shameer, Jean-Philippe,
>
> On 12/4/20 11:20 AM, Shameerali Kolothum Thodi wrote:
>> Hi Jean,
>>
>>> -Original Message-
>>> From: Jean-Philippe Brucker [mailto:jean-phili...@li
executing the test. This patch moves the assignment after the
kvm_vgic_map_resources().
Signed-off-by: Eric Auger
---
v1 -> v2:
- slight reword of the commit msg (for instance)
---
arch/arm64/kvm/arm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/arm.c b/a
R.Last bit
still makes sense for architecture compliance.
This patch restores its support (if the redistributor region
was set) while keeping the code safe.
Signed-off-by: Eric Auger
---
arch/arm64/kvm/vgic/vgic-mmio-v3.c | 7 ++-
include/kvm/arm_vgic.h | 1 +
2 files changed, 7
,write}.
Signed-off-by: Eric Auger
---
v1 -> v2:
- reworded the commit message as suggested by Alexandru
---
arch/arm64/kvm/vgic/vgic-mmio.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/kvm/vgic/vgic-mmio.c b/arch/arm64/kvm/vgic/vgic-mmio.c
in
group
and especially the GICR_TYPER read. The goal was to test the case
recently fixed by commit 23bde34771f1
("KVM: arm64: vgic-v3: Drop the reporting of GICR_TYPER.Last for userspace").
The API under test can be found at
Documentation/virt/kvm/devices/arm-vgic-v3.rst
Signed-off-by:
kvm_arch_vcpu_precreate() returns -EBUSY if the vgic is
already initialized. So let's document that KVM_DEV_ARM_VGIC_CTRL_INIT
must be called after all vcpu creations.
Signed-off-by: Eric Auger
---
v1 -> v2:
- Must be called after all vcpu creations ->
Must be called after all
rm64: Implement
KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION")
Cc: sta...@vger.kernel.org#v4.17+
Signed-off-by: Eric Auger
Reviewed-by: Alexandru Elisei
---
v1 -> v2:
- in the commit message, remove the statement that the index always is 0
- add Alexandru's R-b
---
arch/arm64/kvm/vgic/vgic-kvm-devi
On vgic_dist_destroy(), the addresses are not reset. However for
kvm selftest purpose this would allow to continue the test execution
even after a failure when running KVM_RUN. So let's reset the
base addresses.
Signed-off-by: Eric Auger
---
v1 -> v2:
- use dist-> in the else and
vgic_register_redist_iodev().
In such a case, remove the newly added redistributor region and free
it.
Signed-off-by: Eric Auger
---
v1 -> v2:
- fix the commit message and split declaration/assignment of rdreg
---
arch/arm64/kvm/vgic/vgic-mmio-v3.c | 8 +++-
1 file changed, 7 insertions(+), 1 delet
by looking at the count field.
Signed-off-by: Eric Auger
---
v1 -> v2:
- simplify the check sequence
---
arch/arm64/kvm/vgic/vgic-mmio-v3.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c
b/arch/arm64/kvm/vgic/vgic-mmio
they can be augmented with a lot more
register access tests, but let's try to move forward incrementally ...
Best Regards
Eric
This series can be found at:
https://github.com/eauger/linux/tree/vgic_kvmselftests_v2
History:
- Took into account all comments from Marc and Alexandru's ex
Hi Alexandru,
On 1/12/21 6:02 PM, Alexandru Elisei wrote:
> Hi Eric,
>
> On 12/12/20 6:50 PM, Eric Auger wrote:
>> Commit 23bde34771f1 ("KVM: arm64: vgic-v3: Drop the
>> reporting of GICR_TYPER.Last for userspace") temporarily fixed
>> a bug identified whe
Hi Alexandru,
On 1/12/21 3:55 PM, Alexandru Elisei wrote:
> Hi Eric,
>
> On 12/12/20 6:50 PM, Eric Auger wrote:
>> has_run_once is set to true at the beginning of
>> kvm_vcpu_first_run_init(). This generally is not an issue
>> except when exercising the code with K
Hi Alexandru,
On 1/6/21 5:32 PM, Alexandru Elisei wrote:
> Hi Eric,
>
> On 12/12/20 6:50 PM, Eric Auger wrote:
>> KVM_DEV_ARM_VGIC_GRP_ADDR group doc says we should return
>> -EEXIST in case the base address of the redist is already set.
>> We currently return -EINVA
> On Jan 13, 2021, at 1:41 PM, Jarkko Sakkinen
> wrote:
>
> On Tue, Jan 12, 2021 at 02:57:39PM +, David Howells wrote:
>> Eric Snowberg wrote:
>>
>>>> On Dec 10, 2020, at 2:49 AM, David Howells wrote:
>>>>
>>>> Eric Snowber
On Wed, Jan 13, 2021 at 9:12 PM Enke Chen wrote:
>
> From: Enke Chen
>
> The TCP session does not terminate with TCP_USER_TIMEOUT when data
> remain untransmitted due to zero window.
>
> The number of unanswered zero-window probes (tcp_probes_out) is
> reset to zero with incoming acks irrespectiv
Hi Marc,
On 12/28/20 4:35 PM, Marc Zyngier wrote:
> Hi Eric,
>
> On Sat, 12 Dec 2020 18:50:04 +0000,
> Eric Auger wrote:
>>
>> vgic_register_all_redist_iodevs may succeed while
>> vgic_register_all_redist_iodevs fails. For example this can happen
>
> Th
Hi Alexandru,
On 1/12/21 4:39 PM, Alexandru Elisei wrote:
> Hi Eric,
>
> On 12/12/20 6:50 PM, Eric Auger wrote:
>> kvm_arch_vcpu_precreate() returns -EBUSY if the vgic is
>> already initialized. So let's document that KVM_DEV_ARM_VGIC_CTRL_INIT
>> must be
Hi Marc,
On 12/28/20 4:41 PM, Marc Zyngier wrote:
> On Sat, 12 Dec 2020 18:50:05 +,
> Eric Auger wrote:
>>
>> On vgic_dist_destroy(), the addresses are not reset. However for
>> kvm selftest purpose this would allow to continue the test execution
>> even after
Hi Alexandru,
On 1/6/21 6:12 PM, Alexandru Elisei wrote:
> Hi Eric,
>
> The patch looks correct to me. kvm_vgic_addr() masks out all the bits except
> index
> from addr, so we don't need to do it in vgic_get_common_attr():
>
> Reviewed-by: Alexandru Elisei
>
&g
Hi Alexandru,
On 1/12/21 5:16 PM, Alexandru Elisei wrote:
> Hi Eric,
>
> On 1/12/21 4:04 PM, Alexandru Elisei wrote:
>> Hi Eric,
>>
>> On 12/12/20 6:50 PM, Eric Auger wrote:
>>> Instead of converting the vgic_io_device handle to a kvm_io_device
>>&g
On Wed, Jan 13, 2021 at 6:03 PM Jakub Kicinski wrote:
>
> On Wed, 13 Jan 2021 05:46:05 +0100 Eric Dumazet wrote:
> > On Wed, Jan 13, 2021 at 2:02 AM Jakub Kicinski wrote:
> > >
> > > On Tue, 12 Jan 2021 13:23:16 +0100 Eric Dumazet wrote:
> > > > On Tue,
Alexey Gladkov writes:
We might want to use refcount_t instead of atomic_t. Not a big deal
either way.
> Signed-off-by: Alexey Gladkov
> ---
> include/linux/user_namespace.h | 2 +-
> kernel/ucount.c| 10 +-
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff
The subject is wrong. This should be:
[RFC PATCH v2 2/8] Add a reference to ucounts for each cred.
Further the explanation could use a little work. Something along the
lines of:
For RLIMIT_NPROC and some other rlimits the user_struct that holds the
global limit is kept alive for the lifetime
Hi Shameer,
On 1/8/21 6:05 PM, Shameerali Kolothum Thodi wrote:
> Hi Eric,
>
>> -Original Message-----
>> From: Eric Auger [mailto:eric.au...@redhat.com]
>> Sent: 18 November 2020 11:22
>> To: eric.auger@gmail.com; eric.au...@redhat.com;
>> io...@list
On Wed, Jan 13, 2021 at 2:37 PM Alexander Lobakin wrote:
>
> Instead of calling kmem_cache_alloc() every time when building a NAPI
> skb, (re)use skbuff_heads from napi_alloc_cache.skb_cache. Previously
> this cache was only used for bulk-freeing skbuff_heads consumed via
> napi_consume_skb() or _
On Wed, Jan 13, 2021 at 2:02 AM Jakub Kicinski wrote:
>
> On Tue, 12 Jan 2021 13:23:16 +0100 Eric Dumazet wrote:
> > On Tue, Jan 12, 2021 at 12:08 PM Alexander Lobakin wrote:
> > >
> > > From: Edward Cree
> > > Date: Tue, 12 Jan 2021 09:54:04 +
>
On Tue, Jan 12, 2021 at 11:48 PM Yuchung Cheng wrote:
>
> On Tue, Jan 12, 2021 at 2:31 PM Enke Chen wrote:
> >
> > From: Enke Chen
> >
> > In this patch two issues with TCP keepalives are fixed:
> >
> > 1) TCP keepalive does not timeout when there are data waiting to be
> >delivered and then
From: Eric Biggers
The RNDRESEEDCRNG ioctl reseeds the primary_crng from itself, which
doesn't make sense. Reseed it from the input_pool instead.
Fixes: d848e5f8e1eb ("random: add new ioctl RNDRESEEDCRNG")
Cc: sta...@vger.kernel.org
Cc: linux-cry...@vger.kernel.org
Cc: Andy
From: Eric Biggers
Remove some dead code that was left over following commit 90ea1c6436d2
("random: remove the blocking pool").
Cc: linux-cry...@vger.kernel.org
Cc: Andy Lutomirski
Cc: Jann Horn
Cc: Theodore Ts'o
Reviewed-by: Andy Lutomirski
Signed-off-by: Eric Biggers
---
From: Eric Biggers
On big endian CPUs, the ChaCha20-based CRNG is using the wrong
endianness for the ChaCha20 constants.
This doesn't matter cryptographically, but technically it means it's not
ChaCha20 anymore. Fix it to always use the standard constants.
Cc: linux-cry...@vger.ker
On Tue, Jan 12, 2021 at 7:26 PM Alexander Lobakin wrote:
>
> From: Eric Dumazet
> Date: Tue, 12 Jan 2021 13:32:56 +0100
>
> > On Tue, Jan 12, 2021 at 11:56 AM Alexander Lobakin wrote:
> >>
> >
> >>
> >> Ah, I should've mentioned that I
d appreciate any feedback on that series as well.
Thanks
> David
> ---
> commit 8913866babb96fcfe452aac6042ca8862d4c0b53
> Author: Eric Snowberg
> Date: Tue Sep 15 20:49:27 2020 -0400
>
>certs: Add EFI_CERT_X509_GUID support for dbx entries
>
>The Secure Boo
ebied...@xmission.com (Eric W. Biederman) writes:
> So there is the basic question do we want to read the raw bytes on disk
> or do we want to return something meaningful to the reader. As the
> existing tools use the xattr interface to set/clear fscaps returning
> data to user space
Miklos Szeredi writes:
> On Tue, Jan 12, 2021 at 1:15 AM Eric W. Biederman
> wrote:
>>
>> Miklos Szeredi writes:
>>
>> > On Fri, Jan 01, 2021 at 11:35:16AM -0600, Eric W. Biederman wrote:
>
>> > For one: a v2 fscap is supposed to be equivalent t
On Tue, Jan 12, 2021 at 11:56 AM Alexander Lobakin wrote:
>
>
> Ah, I should've mentioned that I use UDP GRO Fraglists, so these
> numbers are for GRO.
>
Right, this suggests UDP GRO fraglist is a pathological case of GRO,
not saving memory.
Real GRO (TCP in most cases) will consume one skb, an
On Tue, Jan 12, 2021 at 12:08 PM Alexander Lobakin wrote:
>
> From: Edward Cree
> Date: Tue, 12 Jan 2021 09:54:04 +
>
> > Without wishing to weigh in on whether this caching is a good idea...
>
> Well, we already have a cache to bulk flush "consumed" skbs, although
> kmem_cache_free() is gene
set module is mandated (except if reset_required is forced to
0), I am wondering if we shouldn't try to turn the reset module into a
"specialization" module and put the msi hooks there. I am afraid we may
end up having modules for each and every vfio platform feature
specialization. At the moment that's fully bearable but I can't predict
what's next.
As the mandated feature is the reset capability maybe we could just keep
the config/module name terminology, tune the kconfig help message to
mention the msi support in case of flex-rm?
What do you think?
Thanks
Eric
> +
> +MODULE_LICENSE("GPL v2");
> +MODULE_AUTHOR("Broadcom");
>
Hi Vikas,
On 1/5/21 6:53 AM, Vikas Gupta wrote:
> On Tue, Dec 22, 2020 at 10:57 PM Auger Eric wrote:
>>
>> Hi Vikas,
>>
>> On 12/14/20 6:45 PM, Vikas Gupta wrote:
>>> MSI support for platform devices.The MSI block
>>> is added as an extended IRQ whic
On Mon, Jan 11, 2021 at 7:27 PM Alexander Lobakin wrote:
>
> Inspired by cpu_map_kthread_run() and _kfree_skb_defer() logics.
>
> Currently, all sorts of skb allocation always do allocate
> skbuff_heads one by one via kmem_cache_alloc().
> On the other hand, we have percpu napi_alloc_cache to stor
;crypto_cap_array);
> out:
> /* Indicate that init failed by clearing UFSHCD_CAP_CRYPTO */
> hba->caps &= ~UFSHCD_CAP_CRYPTO;
Looks fine, feel free to add:
Reviewed-by: Eric Biggers
I think this was here to free the memory in the case where the crypto support
gets disab
Miklos Szeredi writes:
> On Fri, Jan 01, 2021 at 11:35:16AM -0600, Eric W. Biederman wrote:
>> Miklos Szeredi writes:
>>
>> > cap_convert_nscap() does permission checking as well as conversion of the
>> > xattr value conditionally based on fs's user-ns.
er_fork that sets RLIMIT_NPROC runs as
never_fork_user and sets RLIMIT_NPROC to 1 in it's systemd service file.
Further suppose there is a user bob who has two containers he wants to
run: container1 and container2. Both containers start the never_fork
service.
Bob first starts container1 and inside it the never_fork service starts.
Bob starts container2 and the never_fork service fails to start.
Does that make it clear that it is the count of the processes that would
exceed 1 if both instances of the never_fork service starts that would
be the problem?
Eric
make-work Google AIs spraying zeroday code in
> public places and the community developers having to clean up the mess.
syzkaller is an open source project that implements a coverage-guided fuzzer for
multiple operating system kernels; it's not "Google AI".
Anyone can run syzkaller (either by itself, or as part of a syzbot instance) and
find the same bugs.
- Eric
; > + }
> > >
> > > desc->tfm = *tfm;
> > >
> > > rc = crypto_shash_init(desc);
> > > if (rc) {
> > > + if (tmp_tfm)
> > > + crypto_free_shash(tmp_tfm);
> > > kfree(desc);
> > > return ERR_PTR(rc);
> > > }
> >
> > There's no need to check for NULL before calling crypto_free_shash().
> >
>
> I find there is a crypto_shash_tfm() in the definition of
> crypto_free_shash(). Will this lead to null pointer dereference
> when we use it to free a NULL pointer?
>
No. It does &tfm->base, not tfm->base.
- Eric
uses this support (on 32bit where dosemu can use vm86)?
It may still be a valid removal target I just wanted to point out what
the original user was.
Eric
> Cc: Andrea Arcangeli
> Cc: Linux-MM
> Cc: Jason Gunthorpe
> Cc: x...@kernel.org
> Cc: Linus Torvalds
> Cc: Matthew Wi
+Jason, since this looks WireGuard-related.
On Sat, Jan 09, 2021 at 05:05:24AM -0800, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:73d62e81 kmsan: random: prevent boot-time reports in _mix_..
> git tree: https://github.com/google/kmsan.git master
> co
(desc);
> if (rc) {
> + if (tmp_tfm)
> + crypto_free_shash(tmp_tfm);
> kfree(desc);
> return ERR_PTR(rc);
> }
There's no need to check for NULL before calling crypto_free_shash().
- Eric
r just a wrapper for the
shash API, and it doesn't handle modules being dynamically loaded/unloaded.
So switching to it may cause a performance regression.
What I'd recommend is making crc32c_le() able to call architecture-speccific
implementations directly, similar to blake2s() and chacha20() in lib/crypto/.
Then there would be no concern about when modules get loaded, etc...
- Eric
iguring things
when a new crypto module is loaded (like what lib/crc-t10dif.c does).
Until one of those is done, switching to crc32c_le() might cause performance
regressions.
- Eric
HKDF, it would be better to stick to the terminology used in RFC 5869
(https://tools.ietf.org/html/rfc5869), as generally that's what people are most
familiar with for HKDF. It also matches the HKDF paper
(https://eprint.iacr.org/2010/264.pdf) more closely.
- Eric
truct crypto_shash *hmac_tfm,
> > const u8 *key, size_t keysize,
> > const u8 *salt, size_t saltsize);
>
> I wanted to have an identical interface for all types of KDFs to allow turning
> them into a template eventually. For example, SP800-108 KDFs only have one
> parameter. Hence the use of a kvec.
But the API being provided is a library function specifically for HKDF.
So there's no need to make it conform to some other API.
- Eric
fied in RFC5869, it is
> optional. In case such context is not provided, the caller must provide
> NULL / 0 for the info / info_nvec parameters.
Any reason not to call this crypto_hkdf_expand() to match the specification?
- Eric
;counter, 1, tmp);
> - if (err)
> - goto out;
> - memcpy(&okm[i], tmp, okmlen - i);
> - memzero_explicit(tmp, sizeof(tmp));
> - } else {
> - err = crypto_shash_finup(desc, &counter, 1, &okm[i]);
> - if (err)
> - goto out;
> - }
> - counter++;
> - prev = &okm[i];
> - }
> - err = 0;
> -out:
> if (unlikely(err))
> memzero_explicit(okm, okmlen); /* so caller doesn't need to */
> - shash_desc_zero(desc);
Shouldn't crypto_hkdf_generate() handle the above memzero_explicit() of the
output buffer on error, so that all callers don't need to do it?
- Eric
On Wed, Jan 06, 2021 at 10:59:24PM -0800, Eric Biggers wrote:
> On Thu, Jan 07, 2021 at 07:37:05AM +0100, Stephan Mueller wrote:
> > Am Montag, dem 04.01.2021 um 14:20 -0800 schrieb Eric Biggers:
> > > On Mon, Jan 04, 2021 at 10:45:57PM +0100, Stephan Müller wrote:
> >
On Thu, Jan 07, 2021 at 07:37:05AM +0100, Stephan Mueller wrote:
> Am Montag, dem 04.01.2021 um 14:20 -0800 schrieb Eric Biggers:
> > On Mon, Jan 04, 2021 at 10:45:57PM +0100, Stephan Müller wrote:
> > > The HKDF addition is used to replace the implementation in the files
Al Viro writes:
> On Mon, Jan 04, 2021 at 06:47:38PM -0600, Eric W. Biederman wrote:
>> >> It is defined in the Ubuntu kernel configs I've got lurking:
>> >> Both 3.8.0-19_generic (Ubuntu 13.04) and 5.4.0-56_generic (probably
>> >> 20.04).
>>
Andy Lutomirski writes:
>> On Jan 4, 2021, at 2:36 PM, David Laight wrote:
>>
>> From: Eric W. Biederman
>>> Sent: 04 January 2021 20:41
>>>
>>> Al Viro writes:
>>>
>>>> On Mon, Jan 04, 2021 at 12:16:56PM +,
fstests -c ext4 generic/582' should be
enough for this, though you could run all the tests if you want.
- Eric
us there.
So I don't think we have any cases where we actually need a flag that
is independent of the system call but we have come very close.
For people who want to optimize I suggest tracking down the handful of
users of x32 and see if x32 can be made to just go away.
Eric
On Fri, Nov 20, 2020 at 10:52:54AM -0800, Eric Biggers wrote:
> On Mon, Oct 26, 2020 at 09:33:54AM -0700, Eric Biggers wrote:
> > On Tue, Oct 06, 2020 at 08:51:45PM -0700, Eric Biggers wrote:
> > > On Fri, Sep 18, 2020 at 02:57:05PM -0700, Eric Biggers wrote:
> > > >
On Fri, Nov 20, 2020 at 10:52:35AM -0800, Eric Biggers wrote:
> On Mon, Oct 26, 2020 at 09:34:03AM -0700, Eric Biggers wrote:
> > On Tue, Oct 06, 2020 at 08:50:58PM -0700, Eric Biggers wrote:
> > > On Tue, Sep 15, 2020 at 09:36:52PM -0700, Eric Biggers wrote:
> >
On Fri, Nov 20, 2020 at 10:52:14AM -0800, Eric Biggers wrote:
> On Mon, Oct 26, 2020 at 09:33:43AM -0700, Eric Biggers wrote:
> > On Tue, Oct 06, 2020 at 08:50:21PM -0700, Eric Biggers wrote:
> > > On Tue, Sep 15, 2020 at 09:19:08PM -0700, Eric Biggers wrote:
> >
On Tue, Sep 22, 2020 at 09:44:18AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> There's no need for mnt_want_write_file() to increment mnt_writers when
> the file is already open for writing, provided that
> mnt_drop_write_file() is changed to conditionally decrement
RTL8723DS could be handled by btrtl-driver, so add ability to bind it
using device tree.
Signed-off-by: John-Eric Kamps
---
drivers/bluetooth/hci_h5.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bluetooth/hci_h5.c b/drivers/bluetooth/hci_h5.c
index 7be16a7f653b..fb9817f97d45
501 - 600 of 9305 matches
Mail list logo
