Greg KH wrote:
> > Because Alan says that locking down the module parameters needs to be done
> > first. Since I had to go through and modify each module parameter to mark
> > the
> > hardware config ones, it seemed like a good opportunity to label their type
> > (ioport, iomem, irq, etc.) whil
On Tue, Dec 06, 2016 at 10:42:47AM +, David Howells wrote:
> Greg KH wrote:
>
> > What about all of the ways you can change ioports dynamically from
> > ioctls? Or can't python write ioctls to device nodes? :)
>
> Do you mean change the ioport a driver uses by ioctl or actually read/write
Greg KH wrote:
> What about all of the ways you can change ioports dynamically from
> ioctls? Or can't python write ioctls to device nodes? :)
Do you mean change the ioport a driver uses by ioctl or actually read/write an
ioport directly?
Do the following patches that I've already posted addr
On Mon, Dec 05, 2016 at 09:12:27PM +, One Thousand Gnomes wrote:
> On Thu, 01 Dec 2016 16:02:26 +
> David Howells wrote:
>
> > Greg KH wrote:
> >
> > > Also, I think Alan's comment about it the last time it came up was more
> > > like
> > > a "look at all of the other ways you could do
> If the parameters plausibly make it possible for root to modify the
> kernel in interesting ways, then restricting them makes sense. My gut
> sense is that parameters that allow the alteration of the base address
> of memory mapped devices are clearly a problem in this respect, but port
> io
On Thu, 01 Dec 2016 16:02:26 +
David Howells wrote:
> Greg KH wrote:
>
> > Also, I think Alan's comment about it the last time it came up was more like
> > a "look at all of the other ways you could do bad things to hardware!"
> > comment, not a "you need to also do this thing too!" type of
On Fri, Dec 02, 2016 at 02:59:22PM +, David Howells wrote:
> Greg KH wrote:
>
> > > If root is able to modify the behaviour of verified code after it was
> > > verified, then the value of that verification is reduced. Ensuring that
> > > the code remains trustworthy is vital in a number of
Greg KH wrote:
> > If root is able to modify the behaviour of verified code after it was
> > verified, then the value of that verification is reduced. Ensuring that
> > the code remains trustworthy is vital in a number of security use cases.
>
> Ok, but why are you now deciding to somehow try
On Fri, Dec 02, 2016 at 07:55:30AM +0100, Greg KH wrote:
> On Fri, Dec 02, 2016 at 03:07:00AM +, Matthew Garrett wrote:
> > If root is able to modify the behaviour of verified code after it was
> > verified, then the value of that verification is reduced. Ensuring that
> > the code remains tr
On Fri, Dec 02, 2016 at 03:07:00AM +, Matthew Garrett wrote:
> On Thu, Dec 01, 2016 at 04:01:35PM +0100, Greg KH wrote:
>
> > First off, this "secure boot support" massive patchset has not gone
> > anywhere yet, so why do this now?
>
> Because David ended up with the short straw when distro m
On Thu, Dec 01, 2016 at 04:01:35PM +0100, Greg KH wrote:
> First off, this "secure boot support" massive patchset has not gone
> anywhere yet, so why do this now?
Because David ended up with the short straw when distro maintainers
talked about this at LPC.
> Secure boot is a trust that the prev
Greg KH wrote:
> Also, I think Alan's comment about it the last time it came up was more like
> a "look at all of the other ways you could do bad things to hardware!"
> comment, not a "you need to also do this thing too!" type of request.
Alan said:
You need to filter or lock down kerne
On Thu, Dec 01, 2016 at 12:29:47PM +, David Howells wrote:
> 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).
>
> This will enable such parameters to be locked down in t
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).
This will enable such parameters to be locked down in the core parameter
parser for secure boot support.
I've also included ann
14 matches
Mail list logo
