| unsigned long val = *addr & GENMASK(size - 1, 0);
| ^
drivers/iommu/intel/iommu.c:2115:18: note: while referencing 'max_pde'
2115 | int pds, max_pde;
| ^~~
Signed-off-by: Kees Cook
---
drivers/iommu/intel/iommu.c
On Tue, Sep 28, 2021 at 05:22:29PM -0500, Gustavo A. R. Silva wrote:
> Use 2-factor argument form kvcalloc() instead of kvzalloc().
>
> Link: https://github.com/KSPP/linux/issues/162
> Signed-off-by: Gustavo A. R. Silva
Looks right.
Reviewed-by: Kees Cook
-
Cc: Joerg Roedel
Cc: Will Deacon
Cc: iommu@lists.linux-foundation.org
Signed-off-by: Kees Cook
---
drivers/iommu/amd/init.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
index bdcf167b4afe..70506d6175e9 100644
--- a/driv
On Wed, Oct 28, 2020 at 10:13:52PM +0100, Thomas Gleixner wrote:
> On Wed, Oct 28 2020 at 13:49, Kees Cook wrote:
> > On Sat, Oct 24, 2020 at 10:35:15PM +0100, David Woodhouse wrote:
> >> + memset(, 0, sizeof(*msg);
> >
> > This should be:
> >
);
This should be:
+ memset(msg, 0, sizeof(*msg);
https://groups.google.com/g/clang-built-linux/c/N-DfCPz3alg
> + msg->address_hi = X86_MSI_BASE_ADDRESS_HIGH;
> + msg->arch_addr_lo.base_address = X86_MSI_BASE_ADDRESS_LOW;
> + msg->arch_addr_lo.destid_0_7 = in
On Wed, Oct 30, 2019 at 07:09:21PM +0100, Christoph Hellwig wrote:
> On Wed, Oct 30, 2019 at 10:18:49AM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Oct 29, 2019 at 02:34:22PM -0700, Kees Cook wrote:
> > > As we've seen from USB and other areas[1], we need to always do runtime
&g
] https://git.kernel.org/linus/3840c5b78803b2b6cc1ff820100a74a092c40cbb
-Kees
Kees Cook (2):
dma-mapping: Add vmap checks to dma_map_single()
usb: core: Remove redundant vmap checks
drivers/usb/core/hcd.c | 8 +---
include/linux/dma-mapping.h | 6 ++
2 files changed, 7 insertions
://git.kernel.org/linus/3840c5b78803b2b6cc1ff820100a74a092c40cbb
Suggested-by: Laura Abbott
Signed-off-by: Kees Cook
---
include/linux/dma-mapping.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 4a1c4fca475a..54de3c496407
Now that the vmap area checks are being performed in the DMA
infrastructure directly, there is no need to repeat them in USB.
Signed-off-by: Kees Cook
---
drivers/usb/core/hcd.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core
Now that the vmap area checks are being performed in the DMA
infrastructure directly, there is no need to repeat them in USB.
Signed-off-by: Kees Cook
---
drivers/usb/core/hcd.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core
://git.kernel.org/linus/3840c5b78803b2b6cc1ff820100a74a092c40cbb
Suggested-by: Laura Abbott
Signed-off-by: Kees Cook
---
include/linux/dma-mapping.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 4a1c4fca475a..ff4e91c66f44
/201910021341.7819A660@keescook
Kees Cook (2):
dma-mapping: Add vmap checks to dma_map_single()
usb: core: Remove redundant vmap checks
drivers/usb/core/hcd.c | 8 +---
include/linux/dma-mapping.h | 6 ++
2 files changed, 7 insertions(+), 7 deletions(-)
--
2.17.1
-by: Kees Cook
---
v2: Only add is_vmalloc_addr()
v1: https://lore.kernel.org/lkml/201910021341.7819A660@keescook
---
drivers/usb/core/hcd.c | 8 +---
include/linux/dma-mapping.h | 7 +++
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core
On Fri, Oct 04, 2019 at 07:50:54PM +0100, Robin Murphy wrote:
> On 03/10/2019 22:38, Kees Cook wrote:
> > What do you think about the object_is_on_stack() check? That does a
> > dereference through "current" to find the stack bounds...
>
> I guess it depends what
On Thu, Oct 03, 2019 at 10:42:45AM +0100, Robin Murphy wrote:
> On 03/10/2019 00:58, Kees Cook wrote:
> > On Wed, Oct 02, 2019 at 10:15:43PM +0100, Robin Murphy wrote:
> > > Hi Kees,
> > >
> > > On 2019-10-02 9:46 pm, Kees Cook wrote:
> > > >
On Wed, Oct 02, 2019 at 04:58:39PM -0700, Kees Cook wrote:
> In the USB case, it'll actually refuse to do the operation. Should
> dma_map_single() similarly fail? I could push these checks down into
> dma_map_single(), which would be a no-change on behavior for USB and
> gain the c
On Wed, Oct 02, 2019 at 10:15:43PM +0100, Robin Murphy wrote:
> Hi Kees,
>
> On 2019-10-02 9:46 pm, Kees Cook wrote:
> > As we've seen from USB and other areas, we need to always do runtime
> > checks for DMA operating on memory regions that might be remapped. This
> >
in a few recent reports).
Suggested-by: Laura Abbott
Signed-off-by: Kees Cook
---
include/linux/dma-debug.h | 8
include/linux/dma-mapping.h | 8 +++-
kernel/dma/debug.c | 16
3 files changed, 7 insertions(+), 25 deletions(-)
diff --git a/include/linux
On Thu, Apr 18, 2019 at 7:35 AM Khalid Aziz wrote:
>
> On 4/17/19 11:41 PM, Kees Cook wrote:
> > On Wed, Apr 17, 2019 at 11:41 PM Andy Lutomirski wrote:
> >> I don't think this type of NX goof was ever the argument for XPFO.
> >> The main argument I've heard is
t's much easier to feel out the linear
mapping address than for the others. But yes, all of those same attack
primitives are possible in other memory areas (though most are NX),
and plenty of exploits have done such things.
--
Kees Cook
___
iommu mai
This removes needless use of '%p', and refactors the printk calls to
use pr_*() helpers instead.
Signed-off-by: Kees Cook
---
kernel/dma/swiotlb.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index
Gleixner <t...@linutronix.de>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: "H. Peter Anvin" <h...@zytor.com>
Cc: x...@kernel.org
Cc: iommu@lists.linux-foundation.org
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
arch/x86/kernel/pci-calgary_64.c | 8 +++-
1 file change
On Mon, Dec 5, 2016 at 2:47 PM, David Woodhouse <dw...@infradead.org> wrote:
> On Mon, 2016-12-05 at 14:18 -0800, Kees Cook wrote:
>> Hm, I have no idea. :) What would I look for in the BIOS?
>
> For a start, what is the actual failure mode?
Based on initial testing (not
On Mon, Dec 5, 2016 at 2:07 PM, David Woodhouse <dw...@infradead.org> wrote:
> On Mon, 2016-12-05 at 13:58 -0800, Kees Cook wrote:
>> This blacklists the Q35 integrated graphics so IOMMU can be otherwise
>> enabled. Without this, a Q35 system can only enable IOMMU when booting
Expansion ROM at [disabled]
Capabilities:
Kernel driver in use: i915
Kernel modules: i915
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/iommu/intel-iommu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/intel-iommu.c b/drivers
This makes sure it won't be possible to accidentally leak format
strings into iommu device names. Current name allocations are safe,
but this makes the %s explicit.
Signed-off-by: Kees Cook keesc...@chromium.org
---
drivers/iommu/dmar.c| 2 +-
drivers/iommu/intel-iommu.c | 2 +-
2 files
26 matches
Mail list logo