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
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
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
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
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
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
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 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
> >
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 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
://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
] 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
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
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
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 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
-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
);
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 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:
> >
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 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
-
| 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
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
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
26 matches
Mail list logo
