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 h
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
> modifie
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 i
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 store
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 "Co
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 this
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 the
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
mmi
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
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
> > >
> > >
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 in
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 d
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.
T
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 driv
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 sec
15 matches
Mail list logo