Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

One Thousand Gnomes wrote: > > I thought that if I'm changing the module_param annotations anyway then it's > > probably worth bunging in an extra parameter that notes what the parameter > > modifies (ioport, iomem, etc.) for future reference, even if we don't store >

Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

One Thousand Gnomes wrote: > > I thought that if I'm changing the module_param annotations anyway then it's > > probably worth bunging in an extra parameter that notes what the parameter > > modifies (ioport, iomem, etc.) for future reference, even if we don't store > > it. > > With a security

Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

On Tue, 29 Nov 2016 14:03:31 + David Howells wrote: > How about the attached? Obviously it need extending to other drivers. > > I thought that if I'm changing the module_param annotations anyway then it's > probably worth bunging in an extra parameter that notes what

Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

On Tue, 29 Nov 2016 14:03:31 + David Howells wrote: > How about the attached? Obviously it need extending to other drivers. > > I thought that if I'm changing the module_param annotations anyway then it's > probably worth bunging in an extra parameter that notes what the parameter >

Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

On 11/29/2016 08:03 AM, David Howells wrote: How about the attached? Obviously it need extending to other drivers. This is great, I like it a lot better. Reviewed-by: Corey Minyard -corey I thought that if I'm changing the module_param annotations anyway then it's

Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

On 11/29/2016 08:03 AM, David Howells wrote: How about the attached? Obviously it need extending to other drivers. This is great, I like it a lot better. Reviewed-by: Corey Minyard -corey I thought that if I'm changing the module_param annotations anyway then it's probably worth bunging

Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

How about the attached? Obviously it need extending to other drivers. I thought that if I'm changing the module_param annotations anyway then it's probably worth bunging in an extra parameter that notes what the parameter modifies (ioport, iomem, etc.) for future reference, even if we don't

Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

How about the attached? Obviously it need extending to other drivers. I thought that if I'm changing the module_param annotations anyway then it's probably worth bunging in an extra parameter that notes what the parameter modifies (ioport, iomem, etc.) for future reference, even if we don't

Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

David Howells wrote: > It would have to be more like pr_err("Hard-coded device addresses, irqs and > dma channels are not permitted when the kernel is locked down."), possibly > with the addition of either "The driver has been disabled" or "These settings > have been

Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

David Howells wrote: > It would have to be more like pr_err("Hard-coded device addresses, irqs and > dma channels are not permitted when the kernel is locked down."), possibly > with the addition of either "The driver has been disabled" or "These settings > have been ignored". That should be

Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

On 11/28/2016 06:11 PM, David Howells wrote: Corey Minyard wrote: This would prevent any IPMI interface from working if any address was given on the kernel command line. I'm not sure what the best policy is, but that sounds like a possible DOS to me. Okay, reasonable point.

Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

On 11/28/2016 06:11 PM, David Howells wrote: Corey Minyard wrote: This would prevent any IPMI interface from working if any address was given on the kernel command line. I'm not sure what the best policy is, but that sounds like a possible DOS to me. Okay, reasonable point. Can you put

Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

Corey Minyard wrote: > This would prevent any IPMI interface from working if any address was given > on the kernel command line. I'm not sure what the best policy is, but that > sounds like a possible DOS to me. Okay, reasonable point. > Can you put this check in

Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

Corey Minyard wrote: > This would prevent any IPMI interface from working if any address was given > on the kernel command line. I'm not sure what the best policy is, but that > sounds like a possible DOS to me. Okay, reasonable point. > Can you put this check in hardcode_find_bmc()? Thats

Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

On 11/21/2016 05:10 PM, David Howells wrote: One Thousand Gnomes wrote: You need to filter or lock down kernel module options because a lot of modules let you set the I/O port or similar (eg mmio) which means you can hack the entire machine with say the 8250 driver

Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

On 11/21/2016 05:10 PM, David Howells wrote: One Thousand Gnomes wrote: You need to filter or lock down kernel module options because a lot of modules let you set the I/O port or similar (eg mmio) which means you can hack the entire machine with say the 8250 driver just by using it with an

Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

Dominik Brodowski wrote: > For most cases, request_firmware() is being used -- for some rare cases, > however, this alternative interface is provided for. It should be pretty > safe nowadays to make pccard_cis_attr read-only (and who uses PCMCIA > nowadays anyway?).

Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

Dominik Brodowski wrote: > For most cases, request_firmware() is being used -- for some rare cases, > however, this alternative interface is provided for. It should be pretty > safe nowadays to make pccard_cis_attr read-only (and who uses PCMCIA > nowadays anyway?). Have a look at the top patch

Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

On Thu, Nov 24, 2016 at 05:34:45PM +, David Howells wrote: > Dominik Brodowski wrote: > > > > > - Abort in drivers/pcmcia/cistpl.c::pccard_store_cis() or remove > > > > write access to the "cis" file in > > > >

Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

On Thu, Nov 24, 2016 at 05:34:45PM +, David Howells wrote: > Dominik Brodowski wrote: > > > > > - Abort in drivers/pcmcia/cistpl.c::pccard_store_cis() or remove > > > > write access to the "cis" file in > > > > drivers/pcmcia/cistpl.c::pccard_cis_attr > > > > > >

Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

Dominik Brodowski wrote: > > > - Abort in drivers/pcmcia/cistpl.c::pccard_store_cis() or remove > > > write access to the "cis" file in > > > drivers/pcmcia/cistpl.c::pccard_cis_attr > > > > What is that doing? Allowing the device to be reconfigured? > >

Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

Dominik Brodowski wrote: > > > - Abort in drivers/pcmcia/cistpl.c::pccard_store_cis() or remove > > > write access to the "cis" file in > > > drivers/pcmcia/cistpl.c::pccard_cis_attr > > > > What is that doing? Allowing the device to be reconfigured? > > Exactly. It is a different

Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

On Wed, Nov 23, 2016 at 12:58:26PM +, David Howells wrote: > Dominik Brodowski wrote: > > > You might also need to disable CIS overrides and CIS firmware loading for > > PCMCIA drivers, I presume. That needs two changes: > > > > - Abort in

Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

On Wed, Nov 23, 2016 at 12:58:26PM +, David Howells wrote: > Dominik Brodowski wrote: > > > You might also need to disable CIS overrides and CIS firmware loading for > > PCMCIA drivers, I presume. That needs two changes: > > > > - Abort in drivers/pcmcia/ds.c::pcmcia_load_firmware() or

Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

Dominik Brodowski wrote: > You might also need to disable CIS overrides and CIS firmware loading for > PCMCIA drivers, I presume. That needs two changes: > > - Abort in drivers/pcmcia/ds.c::pcmcia_load_firmware() or disable > the CONFIG_PCMCIA_LOAD_CIS

Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

Dominik Brodowski wrote: > You might also need to disable CIS overrides and CIS firmware loading for > PCMCIA drivers, I presume. That needs two changes: > > - Abort in drivers/pcmcia/ds.c::pcmcia_load_firmware() or disable > the CONFIG_PCMCIA_LOAD_CIS config option permanently.

Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

On Mon, Nov 21, 2016 at 11:10:52PM +, David Howells wrote: > One Thousand Gnomes wrote: > > > You need to filter or lock down kernel module options because a lot of > > modules let you set the I/O port or similar (eg mmio) which means you can > > hack the entire

Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

On Mon, Nov 21, 2016 at 11:10:52PM +, David Howells wrote: > One Thousand Gnomes wrote: > > > You need to filter or lock down kernel module options because a lot of > > modules let you set the I/O port or similar (eg mmio) which means you can > > hack the entire machine with say the 8250

[PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

One Thousand Gnomes wrote: > You need to filter or lock down kernel module options because a lot of > modules let you set the I/O port or similar (eg mmio) which means you can > hack the entire machine with say the 8250 driver just by using it with an > mmio of the

[PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

One Thousand Gnomes wrote: > You need to filter or lock down kernel module options because a lot of > modules let you set the I/O port or similar (eg mmio) which means you can > hack the entire machine with say the 8250 driver just by using it with an > mmio of the right location to patch the