> On Jul 12, 2019, at 8:50 PM, David Miller wrote:
>
> From: Qian Cai
> Date: Fri, 12 Jul 2019 20:27:09 -0400
>
>> Actually, GCC would consider it a const with -O2 optimized level because it
>> found that it was never modified and it does not understand it is a module
>> parameter.
Thanks for the suggestion! I'll try to add a test for libcap to the patch
series as v2 of the series. Probably not next week, though (IETF week).
- Igor
> On Wed, July 17, 2019 7:47 PM Arnaldo Carvalho de Melo wrote:
>
> Em Wed, Jul 17, 2019 at 06:05:51PM -0300, Arnaldo Carvalho de Melo
On Thu, Jul 18, 2019 at 12:01:18PM +0900, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.2.2 release.
> There are 21 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
Hi Thomas,
I can't comment on the objtool stuff as it is a bit outside of my area
of expertise (probably going to be my next major learning project) but I
can comment on the other errors.
On Thu, Jul 18, 2019 at 10:40:09PM +0200, Thomas Gleixner wrote:
> Build fails with:
>
> clang-10:
On Thu, Jul 18, 2019 at 12:00:55PM +0900, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.1.19 release.
> There are 54 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Jul 18, 2019 at 12:01:14PM +0900, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.60 release.
> There are 47 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Jul 18, 2019 at 12:01:30PM +0900, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.186 release.
> There are 54 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Jul 18, 2019 at 12:01:56PM +0900, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.186 release.
> There are 40 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Jul 18, 2019 at 12:00:51PM +0900, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.134 release.
> There are 80 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Jul 18, 2019 at 1:37 PM Michael S. Tsirkin wrote:
>
> On Thu, Jul 18, 2019 at 01:29:14PM -0700, Alexander Duyck wrote:
> > So one thing that is still an issue then is that my approach would
> > only work on the first migration. The problem is the logic I have
> > implemented assumes that
Hi Greg,
> -Original Message-
> From: Eugeniy Paltsev
> Sent: Thursday, February 14, 2019 6:08 PM
> To: linux-snps-...@lists.infradead.org; Vineet Gupta
> Cc: linux-kernel@vger.kernel.org; Alexey Brodkin ;
> Corentin Labbe
> ; khil...@baylibre.com; Eugeniy Paltsev
>
> Subject: [PATCH
On Thu, Jul 18, 2019 at 01:34:03PM -0700, Alexander Duyck wrote:
> On Thu, Jul 18, 2019 at 1:24 PM Michael S. Tsirkin wrote:
> >
> > On Thu, Jul 18, 2019 at 08:34:37AM -0700, Alexander Duyck wrote:
> > > > > > For example we allocate pages until shrinker kicks in.
> > > > > > Fair enough but in
On Thu, Jul 18, 2019 at 04:42:50PM -0400, Michael S. Tsirkin wrote:
> On Thu, Jul 18, 2019 at 01:36:26PM -0700, Andrew Morton wrote:
> > On Thu, 18 Jul 2019 08:26:11 -0400 "Michael S. Tsirkin"
> > wrote:
> >
> > > On Thu, Jul 18, 2019 at 05:27:20PM +0800, Wei Wang wrote:
> > > > Fixes:
Hi!
On Thu, Jul 18, 2019 at 11:19:58AM +0900, Masahiro Yamada wrote:
> On Thu, Jul 18, 2019 at 1:46 AM Segher Boessenkool
> wrote:
> Kbuild always uses thin archives as far as vmlinux is concerned.
>
> But, there are some other call-sites.
>
> masahiro@pug:~/ref/linux$ git grep '$(AR)' --
Lots of comments bitrotted. Fix them up.
Fixes: 418a3ab1e778 (mm/balloon_compaction: List interfaces)
Reviewed-by: Wei Wang
Signed-off-by: Michael S. Tsirkin
Reviewed-by: Ralph Campbell
Acked-by: Nadav Amit
---
mm/balloon_compaction.c | 67 +++--
1 file
From: Wei Wang
A #GP is reported in the guest when requesting balloon inflation via
virtio-balloon. The reason is that the virtio-balloon driver has
removed the page from its internal page list (via balloon_page_pop),
but balloon_page_enqueue_one also calls "list_del" to do the removal.
This is
> On Jun 25, 2019, at 11:57 AM, Peter Zijlstra wrote:
>
> On Tue, Jun 25, 2019 at 11:07:09AM -0400, Qian Cai wrote:
>> On Tue, 2019-06-25 at 16:25 +0200, Peter Zijlstra wrote:
>>> On Tue, Jun 25, 2019 at 10:04:19AM -0400, Qian Cai wrote:
On Tue, 2019-06-25 at 15:52 +0200, Peter Zijlstra
On Thu, Jul 18, 2019 at 01:36:26PM -0700, Andrew Morton wrote:
> On Thu, 18 Jul 2019 08:26:11 -0400 "Michael S. Tsirkin"
> wrote:
>
> > On Thu, Jul 18, 2019 at 05:27:20PM +0800, Wei Wang wrote:
> > > Fixes: 418a3ab1e778 (mm/balloon_compaction: List interfaces)
> > >
> > > A #GP is reported in
Folks,
after picking up Josh's objtool updates I gave clang a test ride again.
clan is built with https://github.com/ClangBuiltLinux/tc-build.git
That's using the llvm master branch. top commit is:
0c99d19470b ("[OPENMP]Fix sharing of threadprivate variables with TLS
support.")
I merged
On Thu, Jul 18, 2019 at 01:29:14PM -0700, Alexander Duyck wrote:
> So one thing that is still an issue then is that my approach would
> only work on the first migration. The problem is the logic I have
> implemented assumes that once we have hinted on a page we don't need
> to do it again. However
On Thu, 18 Jul 2019 08:26:11 -0400 "Michael S. Tsirkin" wrote:
> On Thu, Jul 18, 2019 at 05:27:20PM +0800, Wei Wang wrote:
> > Fixes: 418a3ab1e778 (mm/balloon_compaction: List interfaces)
> >
> > A #GP is reported in the guest when requesting balloon inflation via
> > virtio-balloon. The reason
On 7/18/19 1:26 PM, Dmitry Osipenko wrote:
18.07.2019 22:42, Peter De Schrijver пишет:
On Thu, Jul 18, 2019 at 02:44:56AM +0300, Dmitry Osipenko wrote:
dependencies I am referring are dfll_ref, dfll_soc, and DVFS peripheral
clocks which need to be restored prior to DFLL reinit.
Okay, but
On Thu, Jul 18, 2019 at 12:00:55PM +0900, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.1.19 release.
> There are 54 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Jul 18, 2019 at 1:24 PM Michael S. Tsirkin wrote:
>
> On Thu, Jul 18, 2019 at 08:34:37AM -0700, Alexander Duyck wrote:
> > > > > For example we allocate pages until shrinker kicks in.
> > > > > Fair enough but in fact many it would be better to
> > > > > do the reverse: trigger shrinker
18.07.2019 23:11, Dmitry Osipenko пишет:
> 18.07.2019 22:24, Sowjanya Komatineni пишет:
>>
>> On 7/18/19 12:18 PM, Peter De Schrijver wrote:
>>> On Tue, Jul 16, 2019 at 09:43:16PM +0300, Dmitry Osipenko wrote:
> CPU parents are PLL_X, PLL_P, and dfll. PLL_X always runs at higher
> rate
On Thu, Jul 18, 2019 at 9:07 AM Michael S. Tsirkin wrote:
>
> On Thu, Jul 18, 2019 at 08:34:37AM -0700, Alexander Duyck wrote:
> > On Wed, Jul 17, 2019 at 10:14 PM Michael S. Tsirkin wrote:
> > >
> > > On Wed, Jul 17, 2019 at 09:43:52AM -0700, Alexander Duyck wrote:
> > > > On Wed, Jul 17, 2019
On 7/10/19 4:36 PM, Stephen Rothwell wrote:
> Hi Gustavo,
>
> On Wed, 10 Jul 2019 13:14:10 -0500 "Gustavo A. R. Silva"
> wrote:
>>
>> At some point during this development cycle, we reached the quota of zero
>> fall-through warnings, but people continued introducing such warnings. So,
>> it
18.07.2019 22:42, Peter De Schrijver пишет:
> On Thu, Jul 18, 2019 at 02:44:56AM +0300, Dmitry Osipenko wrote:
>>>
>>> dependencies I am referring are dfll_ref, dfll_soc, and DVFS peripheral
>>> clocks which need to be restored prior to DFLL reinit.
>>
>> Okay, but that shouldn't be a problem if
On Thu, Jul 18, 2019 at 12:03:23PM -0400, Nitesh Narayan Lal wrote:
> For example we allocate pages until shrinker kicks in.
> Fair enough but in fact many it would be better to
> do the reverse: trigger shrinker and then send as many
> free pages as we can to host.
> >>> I'm
Hi all-
I suspect that a bunch of the bugs you're all finding boil down to:
- Nested debug exceptions could corrupt the outer exception's DR6.
- Nested debug exceptions in which *both* exceptions came from the
kernel were probably all kinds of buggy
- Data breakpoints in bad places in the
On Thu, Jul 18, 2019 at 08:34:37AM -0700, Alexander Duyck wrote:
> > > > For example we allocate pages until shrinker kicks in.
> > > > Fair enough but in fact many it would be better to
> > > > do the reverse: trigger shrinker and then send as many
> > > > free pages as we can to host.
> > >
> >
Hi Linus,
The following changes since commit bcc0e65f47def010d8d1c4cf09bdc698fe061b77:
Merge tag 'mips_fixes_5.2_2' of
git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux (2019-07-06 10:32:12
-0700)
are available in the Git repository at:
fec's gpio phy reset properties have been deprecated.
Update the dt-bindings documentation to explicitly mark
them as such, and provide a short description of the
recommended alternative.
Signed-off-by: Sven Van Asbroeck
---
.../devicetree/bindings/net/fsl-fec.txt | 30 +++
Hello Alexey,
Thanks for your review!
Alexey Kardashevskiy writes:
> On 13/07/2019 16:00, Thiago Jung Bauermann wrote:
>> From: Ram Pai
>>
>> These functions are used when the guest wants to grant the hypervisor
>> access to certain pages.
>>
>> Signed-off-by: Ram Pai
>> Signed-off-by:
18.07.2019 22:24, Sowjanya Komatineni пишет:
>
> On 7/18/19 12:18 PM, Peter De Schrijver wrote:
>> On Tue, Jul 16, 2019 at 09:43:16PM +0300, Dmitry Osipenko wrote:
CPU parents are PLL_X, PLL_P, and dfll. PLL_X always runs at higher
rate
so switching to PLL_P during CPUFreq probe
> On Jul 16, 2019, at 5:03 PM, Steven Rostedt wrote:
>
> On Fri, 12 Jul 2019 12:14:47 -0400
> Qian Cai wrote:
>
>> There are many of those warnings.
>>
>> In file included from ./arch/powerpc/include/asm/paca.h:15,
>> from ./arch/powerpc/include/asm/current.h:13,
>>
On 7/18/2019 12:43 PM, Matthew Garrett wrote:
> Add a mechanism to allow LSMs to make a policy decision around whether
> kernel functionality that would allow tampering with or examining the
> runtime state of the kernel should be permitted.
>
> Signed-off-by: Matthew Garrett
> Acked-by: Kees
On 7/18/2019 12:43 PM, Matthew Garrett wrote:
> The lockdown module is intended to allow for kernels to be locked down
> early in boot - sufficiently early that we don't have the ability to
> kmalloc() yet. Add support for early initialisation of some LSMs, and
> then add them to the list of names
> What I keep forgetting in my little arm-imx6 world, is that devicetrees
> aren't in-kernel apis, but that they have out-of-kernel
> dependencies. It makes more sense to to see them as userspace
> apis, albeit directed at firmware/bootloaders, right?
It is an ongoing debate, but generally they
(Sorry to hijack your reply).
On Thu, Jul 18, 2019 at 06:11:48PM +1000, Alexey Kardashevskiy wrote:
> On 13/07/2019 16:00, Thiago Jung Bauermann wrote:
> >From: Ram Pai
> >+static int enter_secure_mode(unsigned long kbase, unsigned long fdt)
> >+{
> >+register uint64_t func asm("r3") =
Hi Andrew,
On Thu, Jul 18, 2019 at 3:41 PM Andrew Lunn wrote:
>
> Hi Sven
>
> One option would be to submit a patch or a patchset changing all
> existing device tree files to make use of the core method. Anybody
> cut/pasting will then automatically use the correct core way of doing
> it.
>
>
On Tue, Jul 16, 2019 at 10:20:33AM +0300, Felipe Balbi wrote:
> TGPIO is a new IP which allows for time synchronization between systems
> without any other means of synchronization such as PTP or NTP. The
> driver is implemented as part of the PTP framework since its features
> covered most of
Clang generate quite a few of those warnings.
drivers/acpi/scan.c:759:28: warning: arithmetic on a null pointer
treated as a cast from integer to pointer is a GNU extension
[-Wnull-pointer-arithmetic]
status = acpi_get_handle(ACPI_ROOT_OBJECT,
obj->string.pointer,
On Thu, Jul 18, 2019 at 12:01:18PM +0900, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.2.2 release.
> There are 21 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
On Thu, Jul 18, 2019 at 12:00:55PM +0900, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.1.19 release.
> There are 54 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Jul 18, 2019 at 12:00:51PM +0900, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.134 release.
> There are 80 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Jul 18, 2019 at 12:01:14PM +0900, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.60 release.
> There are 47 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
Commit-ID: 8c5477e8046ca139bac250386c08453da37ec1ae
Gitweb: https://git.kernel.org/tip/8c5477e8046ca139bac250386c08453da37ec1ae
Author: Zhenzhong Duan
AuthorDate: Tue, 16 Jul 2019 21:18:12 +0800
Committer: Thomas Gleixner
CommitDate: Thu, 18 Jul 2019 21:41:57 +0200
x86, boot: Remove
On Thu, Jul 18, 2019 at 12:01:30PM +0900, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.186 release.
> There are 54 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
Thomas Gleixner writes:
> On Fri, 12 Jul 2019, Thiago Jung Bauermann wrote:
>> diff --git a/include/linux/mem_encrypt.h b/include/linux/mem_encrypt.h
>> index b310a9c18113..f2e399fb626b 100644
>> --- a/include/linux/mem_encrypt.h
>> +++ b/include/linux/mem_encrypt.h
>> @@ -21,23 +21,11 @@
>>
On Thu, Jul 18, 2019 at 12:01:56PM +0900, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.186 release.
> There are 40 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
Commit-ID: 449f328637e3ca62461da04d60ccb35aa5aa21dc
Gitweb: https://git.kernel.org/tip/449f328637e3ca62461da04d60ccb35aa5aa21dc
Author: Zhenzhong Duan
AuthorDate: Tue, 16 Jul 2019 21:17:20 +0800
Committer: Thomas Gleixner
CommitDate: Thu, 18 Jul 2019 21:41:57 +0200
Commit-ID: cd6697b8b8751b65abd7859af55cf06f36b8e716
Gitweb: https://git.kernel.org/tip/cd6697b8b8751b65abd7859af55cf06f36b8e716
Author: Zhenzhong Duan
AuthorDate: Tue, 16 Jul 2019 21:15:57 +0800
Committer: Thomas Gleixner
CommitDate: Thu, 18 Jul 2019 21:41:57 +0200
x86/boot/efi:
From: Jiri Bohac
This is a preparatory patch for kexec_file_load() lockdown. A locked down
kernel needs to prevent unsigned kernel images from being loaded with
kexec_file_load(). Currently, the only way to force the signature
verification is compiling with KEXEC_VERIFY_SIG. This prevents
From: David Howells
Prohibit replacement of the PCMCIA Card Information Structure when the
kernel is locked down.
Suggested-by: Dominik Brodowski
Signed-off-by: David Howells
Signed-off-by: Matthew Garrett
Reviewed-by: Kees Cook
---
drivers/pcmcia/cistpl.c | 5 +
From: Linn Crosetto
>From the kernel documentation (initrd_table_override.txt):
If the ACPI_INITRD_TABLE_OVERRIDE compile option is true, it is possible
to override nearly any ACPI table provided by the BIOS with an
instrumented, modified one.
When lockdown is enabled, the kernel should
From: David Howells
Provided an annotation for module parameters that specify hardware
parameters (such as io ports, iomem addresses, irqs, dma channels, fixed
dma buffers and other types).
Suggested-by: Alan Cox
Signed-off-by: David Howells
Signed-off-by: Matthew Garrett
Reviewed-by: Kees
From: Josh Boyer
There is currently no way to verify the resume image when returning
from hibernate. This might compromise the signed modules trust model,
so until we can work with signed hibernate images we disable it when the
kernel is locked down.
Signed-off-by: Josh Boyer
Signed-off-by:
From: Josh Boyer
This option allows userspace to pass the RSDP address to the kernel, which
makes it possible for a user to modify the workings of hardware. Reject
the option when the kernel is locked down. This requires some reworking
of the existing RSDP command line logic, since the early
Tracefs may release more information about the kernel than desirable, so
restrict it when the kernel is locked down in confidentiality mode by
preventing open().
Signed-off-by: Matthew Garrett
Cc: Steven Rostedt
---
fs/tracefs/inode.c | 38 +++-
efivar_ssdt_load allows the kernel to import arbitrary ACPI code from an
EFI variable, which gives arbitrary code execution in ring 0. Prevent
that when the kernel is locked down.
Signed-off-by: Matthew Garrett
Acked-by: Ard Biesheuvel
Reviewed-by: Kees Cook
Cc: Ard Biesheuvel
Cc:
Print the content of current->comm in messages generated by lockdown to
indicate a restriction that was hit. This makes it a bit easier to find
out what caused the message.
The message now patterned something like:
Lockdown: : is restricted; see man kernel_lockdown.7
Signed-off-by:
From: David Howells
Disallow opening of debugfs files that might be used to muck around when
the kernel is locked down as various drivers give raw access to hardware
through debugfs. Given the effort of auditing all 2000 or so files and
manually fixing each one as necessary, I've chosen to
Systems in lockdown mode should block the kexec of untrusted kernels.
For x86 and ARM we can ensure that a kernel is trustworthy by validating
a PE signature, but this isn't possible on other architectures. On those
platforms we can use IMA digital signatures instead. Add a function to
determine
From: Matthew Garrett
Allowing users to read and write to core kernel memory makes it possible
for the kernel to be subverted, avoiding module loading restrictions, and
also to steal cryptographic information.
Disallow /dev/mem and /dev/kmem from being opened this when the kernel has
been
From: Matthew Garrett
The kexec_load() syscall permits the loading and execution of arbitrary
code in ring 0, which is something that lock-down is meant to prevent. It
makes sense to disable kexec_load() in this situation.
This does not affect kexec_file_load() syscall which can check for a
From: David Howells
Lock down TIOCSSERIAL as that can be used to change the ioport and irq
settings on a serial port. This only appears to be an issue for the serial
drivers that use the core serial code. All other drivers seem to either
ignore attempts to change port/irq or give an error.
From: Matthew Garrett
Any hardware that can potentially generate DMA has to be locked down in
order to avoid it being possible for an attacker to modify kernel code,
allowing them to circumvent disabled module loading or module signing.
Default to paranoid - in future we can potentially relax
From: David Howells
Disallow the use of certain perf facilities that might allow userspace to
access kernel data.
Signed-off-by: David Howells
Signed-off-by: Matthew Garrett
Reviewed-by: Kees Cook
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
---
From: David Howells
The testmmiotrace module shouldn't be permitted when the kernel is locked
down as it can be used to arbitrarily read and write MMIO space. This is
a runtime check rather than buildtime in order to allow configurations
where the same kernel may be run in both locked down or
From: Matthew Garrett
custom_method effectively allows arbitrary access to system memory, making
it possible for an attacker to circumvent restrictions on module loading.
Disable it if the kernel is locked down.
Signed-off-by: Matthew Garrett
Signed-off-by: David Howells
Reviewed-by: Kees
From: David Howells
bpf_read() and bpf_read_str() could potentially be abused to (eg) allow
private keys in kernel memory to be leaked. Disable them if the kernel
has been locked down in confidentiality mode.
Suggested-by: Alexei Starovoitov
Signed-off-by: Matthew Garrett
cc:
From: David Howells
Disallow the creation of perf and ftrace kprobes when the kernel is
locked down in confidentiality mode by preventing their registration.
This prevents kprobes from being used to access kernel memory to steal
crypto data, but continues to allow the use of kprobes from signed
From: David Howells
Disallow access to /proc/kcore when the kernel is locked down to prevent
access to cryptographic data. This is limited to lockdown
confidentiality mode and is still permitted in integrity mode.
Signed-off-by: David Howells
Signed-off-by: Matthew Garrett
Reviewed-by: Kees
From: Matthew Garrett
Writing to MSRs should not be allowed if the kernel is locked down, since
it could lead to execution of arbitrary code in kernel mode. Based on a
patch by Kees Cook.
Signed-off-by: Matthew Garrett
Signed-off-by: David Howells
Acked-by: Kees Cook
Reviewed-by: Thomas
From: Matthew Garrett
IO port access would permit users to gain access to PCI configuration
registers, which in turn (on a lot of hardware) give access to MMIO
register space. This would potentially permit root to trigger arbitrary
DMA, so lock it down by default.
This also implicitly locks
From: Jiri Bohac
When KEXEC_SIG is not enabled, kernel should not load images through
kexec_file systemcall if the kernel is locked down.
[Modified by David Howells to fit with modifications to the previous patch
and to return -EPERM if the kernel is locked down for consistency with
other
From: Dave Young
Kexec reboot in case secure boot being enabled does not keep the secure
boot mode in new kernel, so later one can load unsigned kernel via legacy
kexec_load. In this state, the system is missing the protections provided
by secure boot.
Adding a patch to fix this by retain the
Minor changes to the previous set, other than a significant rework of
the "Ignore acpi_rsdp kernel param" patch to deal with the early parsing
of that parameter under certain circumstances.
While existing LSMs can be extended to handle lockdown policy,
distributions generally want to be able to apply a straightforward
static policy. This patch adds a simple LSM that can be configured to
reject either integrity or all lockdown queries, and can be configured
at runtime (through
From: David Howells
If the kernel is locked down, require that all modules have valid
signatures that we can verify.
I have adjusted the errors generated:
(1) If there's no signature (ENODATA) or we can't check it (ENOPKG,
ENOKEY), then:
(a) If signatures are enforced then
Add a mechanism to allow LSMs to make a policy decision around whether
kernel functionality that would allow tampering with or examining the
runtime state of the kernel should be permitted.
Signed-off-by: Matthew Garrett
Acked-by: Kees Cook
---
include/linux/lsm_hooks.h | 2 ++
The lockdown module is intended to allow for kernels to be locked down
early in boot - sufficiently early that we don't have the ability to
kmalloc() yet. Add support for early initialisation of some LSMs, and
then add them to the list of names when we do full initialisation later.
Early LSMs are
On Thu, Jul 18, 2019 at 02:44:56AM +0300, Dmitry Osipenko wrote:
> >
> > dependencies I am referring are dfll_ref, dfll_soc, and DVFS peripheral
> > clocks which need to be restored prior to DFLL reinit.
>
> Okay, but that shouldn't be a problem if clock dependencies are set up
> properly.
>
>
Currently, evdev stamps events with timestamps acquired in evdev_events.
However, this timestamping may not be accurate in terms of measuring
when the actual event happened. This API allows any 3rd party driver to
be able to call input_set_timestamp, and provide a timestamp that can be
utilized in
On Thu, Jul 18, 2019 at 01:21:36PM -0400, Sven Van Asbroeck wrote:
> Lucas, Fabio,
>
> On Thu, Jul 18, 2019 at 12:52 PM Fabio Estevam wrote:
> >
> > > Not really a fan of this. This will cause existing DTs, which are
> > > provided by the firmware in an ideal world and may not change at the
> >
On Thu, 2019-07-18 at 21:02 +0200, Vasyl Gomonovych wrote:
> Generated by: alloc_cast.cocci
Please look deeper than just the cocci output.
> diff --git a/drivers/scsi/fnic/fnic_debugfs.c
> b/drivers/scsi/fnic/fnic_debugfs.c
[]
> @@ -59,8 +59,7 @@ int fnic_debugfs_init(void)
>
On Thu, Jul 18, 2019 at 09:36:54AM +0200, Jiri Benc wrote:
On Wed, 17 Jul 2019 19:47:57 -0400, Sasha Levin wrote:
It fixes a bug, right?
A bug in selftests. And quite likely, it probably happens only with
some compiler versions.
I don't think patches only touching tools/testing/selftests/
Fix allocation style
Generated by: alloc_cast.cocci
Signed-off-by: Vasyl Gomonovych
---
drivers/scsi/ibmvscsi/ibmvscsi.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c b/drivers/scsi/ibmvscsi/ibmvscsi.c
index 7f66a7783209..7e9b3e409851
The pull request you sent on Thu, 18 Jul 2019 11:02:41 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git
> parisc-5.3-2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/0e2a5b5bd9a6aaec85df347dd71432a1d2d10763
Thank you!
--
The pull request you sent on Thu, 18 Jul 2019 12:07:36 -0700 (PDT):
> git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git
> tags/riscv/for-v5.3-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/0570bc8b7c9b41deba6f61ac218922e7168ad648
Thank you!
--
On Thu, Jul 18, 2019 at 3:06 PM David Miller wrote:
>
> The device tree documentation in the kernel tree is where information
> like this belongs. Yelling at the user in the kernel logs is not.
Good point, thank you. I'll post a patch which will do exactly that.
The pull request you sent on Thu, 18 Jul 2019 13:33:49 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux.git
> tags/modules-for-v5.3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/da0acd7c656c09b362b5095dc8595f8655dc1223
Thank you!
--
The pull request you sent on Wed, 17 Jul 2019 11:29:18 -0400:
> git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
> trace-v5.3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/818e95c768c6607a1df4cf022c00c3c58e2f203e
Thank you!
--
Deet-doot-dot,
On 7/18/19 12:18 PM, Peter De Schrijver wrote:
On Tue, Jul 16, 2019 at 09:43:16PM +0300, Dmitry Osipenko wrote:
CPU parents are PLL_X, PLL_P, and dfll. PLL_X always runs at higher rate
so switching to PLL_P during CPUFreq probe prior to dfll clock enable
should be safe.
AFAIK, PLLX could run
Hi,
On Wed, 2019-07-17 at 22:01 +0200, Thomas Gleixner wrote:
> Add a new entry to the preemption menu which enables the real-time
> support
> for the kernel. The choice is only enabled when an architecture
> supports
> it.
>
> It selects PREEMPT as the RT features depend on it. To achieve that
Fix allocation style
Generated by: alloc_cast.cocci
Signed-off-by: Vasyl Gomonovych
---
drivers/scsi/esas2r/esas2r_ioctl.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/esas2r/esas2r_ioctl.c
b/drivers/scsi/esas2r/esas2r_ioctl.c
index
Commit-ID: b68b9907069a8d3a65bc16a35360bf8f8603c8fa
Gitweb: https://git.kernel.org/tip/b68b9907069a8d3a65bc16a35360bf8f8603c8fa
Author: Josh Poimboeuf
AuthorDate: Wed, 17 Jul 2019 20:36:57 -0500
Committer: Thomas Gleixner
CommitDate: Thu, 18 Jul 2019 21:01:10 +0200
objtool: Support
Commit-ID: 9fe7b7642fe2c5158904d06fe31b740ca0695a01
Gitweb: https://git.kernel.org/tip/9fe7b7642fe2c5158904d06fe31b740ca0695a01
Author: Josh Poimboeuf
AuthorDate: Wed, 17 Jul 2019 20:36:56 -0500
Committer: Thomas Gleixner
CommitDate: Thu, 18 Jul 2019 21:01:10 +0200
objtool: Convert
Commit-ID: e65050b94d8c518fdbee572ea4ca6d352e1fda37
Gitweb: https://git.kernel.org/tip/e65050b94d8c518fdbee572ea4ca6d352e1fda37
Author: Josh Poimboeuf
AuthorDate: Wed, 17 Jul 2019 20:36:55 -0500
Committer: Thomas Gleixner
CommitDate: Thu, 18 Jul 2019 21:01:10 +0200
objtool: Fix seg
701 - 800 of 1341 matches
Mail list logo
