Re: [PATCH v2 00/15] ima: digest list feature

On Thu, Nov 9, 2017 at 4:51 AM, Roberto Sassu <roberto.sa...@huawei.com> wrote: > On 11/8/2017 4:48 PM, Matthew Garrett wrote: >> The code doing the parsing is in the initramfs, which has already been >> measured at boot time. You can guarantee that it's being do

Re: [PATCH v2 00/15] ima: digest list feature

On Thu, Nov 9, 2017 at 4:51 AM, Roberto Sassu wrote: > On 11/8/2017 4:48 PM, Matthew Garrett wrote: >> The code doing the parsing is in the initramfs, which has already been >> measured at boot time. You can guarantee that it's being done by >> trusted code. > > &

Re: [PATCH v2 00/15] ima: digest list feature

On Wed, Nov 8, 2017 at 7:00 AM, Roberto Sassu <roberto.sa...@huawei.com> wrote: > On 11/7/2017 7:06 PM, Matthew Garrett wrote: >> But we're still left in a state where the kernel has to end up >> supporting a number of very niche formats, and userland agility is >>

Re: [PATCH v2 00/15] ima: digest list feature

On Wed, Nov 8, 2017 at 7:00 AM, Roberto Sassu wrote: > On 11/7/2017 7:06 PM, Matthew Garrett wrote: >> But we're still left in a state where the kernel has to end up >> supporting a number of very niche formats, and userland agility is >> tied to the kernel. I think it mak

Re: [PATCH v2 00/15] ima: digest list feature

On Tue, Nov 7, 2017 at 12:53 PM, Roberto Sassu <roberto.sa...@huawei.com> wrote: > On 11/7/2017 3:49 PM, Matthew Garrett wrote: >> RPM's hardly universal, and distributions are in the process of moving >> away from using it for distributing non-core applications (Flatpak and

Re: [PATCH v2 00/15] ima: digest list feature

On Tue, Nov 7, 2017 at 12:53 PM, Roberto Sassu wrote: > On 11/7/2017 3:49 PM, Matthew Garrett wrote: >> RPM's hardly universal, and distributions are in the process of moving >> away from using it for distributing non-core applications (Flatpak and >> Snap are becoming incr

Re: [PATCH v2 00/15] ima: digest list feature

On Tue, Nov 7, 2017 at 2:36 AM, Roberto Sassu wrote: > Finally, digest lists address also the third issue because Linux > distribution vendors already provide the digests of files included in each > RPM package. The digest list is stored in the RPM header, signed by the

Re: [PATCH v2 00/15] ima: digest list feature

On Tue, Nov 7, 2017 at 2:36 AM, Roberto Sassu wrote: > Finally, digest lists address also the third issue because Linux > distribution vendors already provide the digests of files included in each > RPM package. The digest list is stored in the RPM header, signed by the > vendor. RPM's hardly

Re: Fixing CVE-2017-15361

On Wed, Oct 25, 2017 at 6:44 AM, Jarkko Sakkinen wrote: > I'm implementing a fix for CVE-2017-15361 that simply blacklists > vulnerable FW versions. I think this is the only responsible action from > my side that I can do. I'm not sure this is ideal - do Infineon

Re: Fixing CVE-2017-15361

On Wed, Oct 25, 2017 at 6:44 AM, Jarkko Sakkinen wrote: > I'm implementing a fix for CVE-2017-15361 that simply blacklists > vulnerable FW versions. I think this is the only responsible action from > my side that I can do. I'm not sure this is ideal - do Infineon have any Linux tooling for

Re: Allow automatic kernel taint on unsigned module load to be disabled

Hi Jessica, It seems that there's distribution interest in this - any feedback?

Re: Allow automatic kernel taint on unsigned module load to be disabled

Hi Jessica, It seems that there's distribution interest in this - any feedback?

Re: [PATCH v2 2/3] efi: call get_event_log before ExitBootServices

On Thu, Sep 14, 2017 at 11:43 AM, Jarkko Sakkinen wrote: > On Mon, Sep 11, 2017 at 12:00:21PM +0200, Thiebaud Weksteen wrote: >> With TPM 2.0 specification, the event logs may only be accessible by >> calling an EFI Boot Service. Modify the EFI stub to copy the

Re: [PATCH v2 2/3] efi: call get_event_log before ExitBootServices

On Thu, Sep 14, 2017 at 11:43 AM, Jarkko Sakkinen wrote: > On Mon, Sep 11, 2017 at 12:00:21PM +0200, Thiebaud Weksteen wrote: >> With TPM 2.0 specification, the event logs may only be accessible by >> calling an EFI Boot Service. Modify the EFI stub to copy the log area to >> a new Linux-specific

Re: Allow automatic kernel taint on unsigned module load to be disabled

On Tue, Aug 29, 2017 at 10:56 AM, Jessica Yu wrote: > I understand what the patch is doing, what I don't yet understand is > _why_ you would want to remove the unsigned module taint when > CONFIG_MODULE_SIG is enabled. Which distributions are asking for this > exactly, and for

Re: Allow automatic kernel taint on unsigned module load to be disabled

On Tue, Aug 29, 2017 at 10:56 AM, Jessica Yu wrote: > I understand what the patch is doing, what I don't yet understand is > _why_ you would want to remove the unsigned module taint when > CONFIG_MODULE_SIG is enabled. Which distributions are asking for this > exactly, and for what use cases? I

[tip:efi/core] efi/libstub: Enable reset attack mitigation

Commit-ID: ccc829ba3624beb9a703fc995d016b836d9eead8 Gitweb: http://git.kernel.org/tip/ccc829ba3624beb9a703fc995d016b836d9eead8 Author: Matthew Garrett <mj...@google.com> AuthorDate: Fri, 25 Aug 2017 16:50:15 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Sat, 26

[tip:efi/core] efi/libstub: Enable reset attack mitigation

Commit-ID: ccc829ba3624beb9a703fc995d016b836d9eead8 Gitweb: http://git.kernel.org/tip/ccc829ba3624beb9a703fc995d016b836d9eead8 Author: Matthew Garrett AuthorDate: Fri, 25 Aug 2017 16:50:15 +0100 Committer: Ingo Molnar CommitDate: Sat, 26 Aug 2017 09:20:33 +0200 efi/libstub: Enable

Re: [PATCH] Enable reset attack mitigation

On Fri, Aug 18, 2017 at 1:19 PM, Ard Biesheuvel wrote: > OK. I will get it queued. No need to resend, I can apply the fixes locally. Thanks!

Re: [PATCH] Enable reset attack mitigation

On Fri, Aug 18, 2017 at 1:19 PM, Ard Biesheuvel wrote: > OK. I will get it queued. No need to resend, I can apply the fixes locally. Thanks!

Re: [PATCH] Enable reset attack mitigation

On Fri, Aug 18, 2017 at 12:29 PM, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > On 18 August 2017 at 20:08, Matthew Garrett <mj...@google.com> wrote: >> If the kernel doesn't synchronously zero the key when dm-crypt is torn >> down, that feels like a b

Re: [PATCH] Enable reset attack mitigation

On Fri, Aug 18, 2017 at 12:29 PM, Ard Biesheuvel wrote: > On 18 August 2017 at 20:08, Matthew Garrett wrote: >> If the kernel doesn't synchronously zero the key when dm-crypt is torn >> down, that feels like a bug? > > Of course it should. But that is not the point. The poi

Re: [PATCH] Enable reset attack mitigation

On Fri, Aug 18, 2017 at 11:52 AM, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > On 4 August 2017 at 22:20, Matthew Garrett <mj...@google.com> wrote: >> + * Enable reboot attack mitigation. This requests that the firmware clear >> the >> + * RAM on next r

Re: [PATCH] Enable reset attack mitigation

On Fri, Aug 18, 2017 at 11:52 AM, Ard Biesheuvel wrote: > On 4 August 2017 at 22:20, Matthew Garrett wrote: >> + * Enable reboot attack mitigation. This requests that the firmware clear >> the >> + * RAM on next reboot before proceeding with boot, ensuring that any secre

Re: Allow automatic kernel taint on unsigned module load to be disabled

On Thu, Aug 10, 2017 at 4:43 PM, Jessica Yu wrote: > I think I'm missing some context here. Could you provide some more > background and help me understand why we want to go into all this > trouble just to avoid a taint? Was there a recent bug report, mailing > list discussion,

Re: Allow automatic kernel taint on unsigned module load to be disabled

On Thu, Aug 10, 2017 at 4:43 PM, Jessica Yu wrote: > I think I'm missing some context here. Could you provide some more > background and help me understand why we want to go into all this > trouble just to avoid a taint? Was there a recent bug report, mailing > list discussion, etc. that spurred

[PATCH] Make kernel taint on invalid module signatures configurable

to alter the behaviour of the kernel in the situation where signature enforcement is not required. Add a new kernel configuration option to allow the default behaviour to be toggled, and add a kernel parameter in order to allow tainting to be enabled at runtime. Signed-off-by: Matthew Garrett <

[PATCH] Make kernel taint on invalid module signatures configurable

to alter the behaviour of the kernel in the situation where signature enforcement is not required. Add a new kernel configuration option to allow the default behaviour to be toggled, and add a kernel parameter in order to allow tainting to be enabled at runtime. Signed-off-by: Matthew Garrett --- Rusty

Re: [PATCH] Allow automatic kernel taint on unsigned module load to be disabled

On Sun, Aug 6, 2017 at 9:47 PM, Rusty Russell <ru...@rustcorp.com.au> wrote: > Matthew Garrett <mj...@google.com> writes: >> And then you need an entire trusted userland, at which point you can >> assert that the modules are trustworthy without having to validat

Re: [PATCH] Allow automatic kernel taint on unsigned module load to be disabled

On Sun, Aug 6, 2017 at 9:47 PM, Rusty Russell wrote: > Matthew Garrett writes: >> And then you need an entire trusted userland, at which point you can >> assert that the modules are trustworthy without having to validate >> them so you don't need CONFIG_MODULE_SIG anywa

Re: [PATCH] Allow automatic kernel taint on unsigned module load to be disabled

On Sun, Aug 6, 2017 at 7:49 PM, Rusty Russell <ru...@rustcorp.com.au> wrote: > Matthew Garrett <mj...@google.com> writes: >> Binary modules will still be tainted by the license checker. The issue >> is that if you want to enforce module signatures under *some* >>

Re: [PATCH] Allow automatic kernel taint on unsigned module load to be disabled

On Sun, Aug 6, 2017 at 7:49 PM, Rusty Russell wrote: > Matthew Garrett writes: >> Binary modules will still be tainted by the license checker. The issue >> is that if you want to enforce module signatures under *some* >> circumstances, you need to build with CONFIG_MODU

Re: [PATCH] Allow automatic kernel taint on unsigned module load to be disabled

On Sat, Aug 5, 2017 at 11:54 PM, Rusty Russell <ru...@rustcorp.com.au> wrote: > Matthew Garrett <mj...@google.com> writes: >> Distributions may wish to provide kernels that permit loading of >> unsigned modules based on certain policy decisions. > > Sorry, that's w

Re: [PATCH] Allow automatic kernel taint on unsigned module load to be disabled

On Sat, Aug 5, 2017 at 11:54 PM, Rusty Russell wrote: > Matthew Garrett writes: >> Distributions may wish to provide kernels that permit loading of >> unsigned modules based on certain policy decisions. > > Sorry, that's way too vague to accept this patch. > > So I

Re: [PATCH] Enable reset attack mitigation

On Sat, Aug 5, 2017 at 10:34 AM, Lukas Wunner wrote: > Just an innocent question from a bystander, what's the downside of > unconditionally requesting that memory be overwritten? Does it > prolong reboot noticeably? Yes, it's just to avoid stalling reboot for as long as it

Re: [PATCH] Enable reset attack mitigation

On Sat, Aug 5, 2017 at 10:34 AM, Lukas Wunner wrote: > Just an innocent question from a bystander, what's the downside of > unconditionally requesting that memory be overwritten? Does it > prolong reboot noticeably? Yes, it's just to avoid stalling reboot for as long as it takes to clear RAM.

Re: [PATCH] Enable reset attack mitigation

On Sat, Aug 5, 2017 at 2:50 AM, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > On 4 August 2017 at 22:20, Matthew Garrett <mj...@google.com> wrote: >> If a machine is reset while secrets are present in RAM, it may be >> possible for code executed after the rebo

Re: [PATCH] Enable reset attack mitigation

On Sat, Aug 5, 2017 at 2:50 AM, Ard Biesheuvel wrote: > On 4 August 2017 at 22:20, Matthew Garrett wrote: >> If a machine is reset while secrets are present in RAM, it may be >> possible for code executed after the reboot to extract those secrets >> from untouched memory.

[PATCH] Enable reset attack mitigation

. This is done by setting the MemoryOverwriteRequestControl variable at startup. If userspace can ensure that all secrets are removed as part of a controlled shutdown, it can reset this variable to 0 before triggering a hardware reboot. Signed-off-by: Matthew Garrett <mj...@google.com> --- arch/x8

[PATCH] Enable reset attack mitigation

. This is done by setting the MemoryOverwriteRequestControl variable at startup. If userspace can ensure that all secrets are removed as part of a controlled shutdown, it can reset this variable to 0 before triggering a hardware reboot. Signed-off-by: Matthew Garrett --- arch/x86/boot/compressed/eboot.c

[PATCH] Allow automatic kernel taint on unsigned module load to be disabled

Distributions may wish to provide kernels that permit loading of unsigned modules based on certain policy decisions. Right now that results in the kernel being tainted whenever an unsigned module is loaded, which may not be desirable. Add a config option to disable that. Signed-off-by: Matthew

[PATCH] Allow automatic kernel taint on unsigned module load to be disabled

Distributions may wish to provide kernels that permit loading of unsigned modules based on certain policy decisions. Right now that results in the kernel being tainted whenever an unsigned module is loaded, which may not be desirable. Add a config option to disable that. Signed-off-by: Matthew

Re: WMI and Kernel:User interface

atchset, which means that it's functionality that wouldn't exist for the majority of non-server platforms (and an increasing number of server platforms). -- Matthew Garrett | mj...@srcf.ucam.org

Re: WMI and Kernel:User interface

atchset, which means that it's functionality that wouldn't exist for the majority of non-server platforms (and an increasing number of server platforms). -- Matthew Garrett | mj...@srcf.ucam.org

Re: [RFC 0/3] WhiteEgret LSM module

having the system fail in the event of a bug in the whitelisting agent causing it to crash. I think it would be helpful to have more details of exactly what circumstances this is intended to be used in and then figure out whether there's any way to use existing kernel functionality to provide the

Re: [RFC 0/3] WhiteEgret LSM module

having the system fail in the event of a bug in the whitelisting agent causing it to crash. I think it would be helpful to have more details of exactly what circumstances this is intended to be used in and then figure out whether there's any way to use existing kernel functionality to provide the

Re: [PATCH] Allow userspace control of runtime disabling/enabling of driver probing

On Wed, Jan 4, 2017 at 3:53 PM, Matthew Garrett <mj...@coreos.com> wrote: > usb_choose_configuration() hasn't been called at this point, so no - > we don't create any device entries, so there's no way for userspace to > know anything (there isn't even a uevent on device plug). An

Re: [PATCH] Allow userspace control of runtime disabling/enabling of driver probing

On Wed, Jan 4, 2017 at 3:53 PM, Matthew Garrett wrote: > usb_choose_configuration() hasn't been called at this point, so no - > we don't create any device entries, so there's no way for userspace to > know anything (there isn't even a uevent on device plug). And even if > you

Re: [PATCH] Allow userspace control of runtime disabling/enabling of driver probing

Ugh let's try that again in plain text (How does the Android gmail client still not get this right‽) On Wed, Jan 4, 2017 at 2:47 PM, Greg Kroah-Hartman <gre...@linuxfoundation.org> wrote: > On Wed, Jan 04, 2017 at 02:01:00PM -0600, Matthew Garrett wrote: >> On Wed, Jan 4, 2017 a

Re: [PATCH] Allow userspace control of runtime disabling/enabling of driver probing

Ugh let's try that again in plain text (How does the Android gmail client still not get this right‽) On Wed, Jan 4, 2017 at 2:47 PM, Greg Kroah-Hartman wrote: > On Wed, Jan 04, 2017 at 02:01:00PM -0600, Matthew Garrett wrote: >> On Wed, Jan 4, 2017 at 1:47 PM, Greg Kroah-Hartman

Re: [PATCH] Allow userspace to request device probing even if defer_all_probes is true

On Wed, Jan 4, 2017 at 1:42 PM, Greg Kroah-Hartman <gre...@linuxfoundation.org> wrote: > On Wed, Jan 04, 2017 at 12:11:49PM -0600, Matthew Garrett wrote: >> Userspace doesn't know the order that the kernel will use when >> attempting to bind drivers, so punting binding

Re: [PATCH] Allow userspace to request device probing even if defer_all_probes is true

On Wed, Jan 4, 2017 at 1:42 PM, Greg Kroah-Hartman wrote: > On Wed, Jan 04, 2017 at 12:11:49PM -0600, Matthew Garrett wrote: >> Userspace doesn't know the order that the kernel will use when >> attempting to bind drivers, so punting binding out to userspace may >> result i

Re: [PATCH] Allow userspace to request device probing even if defer_all_probes is true

On Wed, Jan 4, 2017 at 2:03 PM, Greg Kroah-Hartman <gre...@linuxfoundation.org> wrote: > On Wed, Jan 04, 2017 at 01:53:45PM -0600, Matthew Garrett wrote: >> If you have two loaded drivers that could bind to the device then the >> order you attempt to bind them in will ma

Re: [PATCH] Allow userspace to request device probing even if defer_all_probes is true

On Wed, Jan 4, 2017 at 2:03 PM, Greg Kroah-Hartman wrote: > On Wed, Jan 04, 2017 at 01:53:45PM -0600, Matthew Garrett wrote: >> If you have two loaded drivers that could bind to the device then the >> order you attempt to bind them in will matter. > > If you have that, you

Re: [PATCH] Allow userspace control of runtime disabling/enabling of driver probing

On Wed, Jan 4, 2017 at 1:47 PM, Greg Kroah-Hartman wrote: > You know the device type and vendor/product id before you authorize it, > you should be able to do this type of detection otherwise it seems > pretty pointless :) You know the vendor and product ID, which

Re: [PATCH] Allow userspace control of runtime disabling/enabling of driver probing

On Wed, Jan 4, 2017 at 1:47 PM, Greg Kroah-Hartman wrote: > You know the device type and vendor/product id before you authorize it, > you should be able to do this type of detection otherwise it seems > pretty pointless :) You know the vendor and product ID, which doesn't tell you whether one of

Re: [PATCH] Allow userspace control of runtime disabling/enabling of driver probing

On Wed, Jan 4, 2017 at 1:46 PM, Greg Kroah-Hartman <gre...@linuxfoundation.org> wrote: > On Wed, Jan 04, 2017 at 12:10:04PM -0600, Matthew Garrett wrote: >> On Wed, Jan 4, 2017 at 3:32 AM, Greg Kroah-Hartman >> <gre...@linuxfoundation.org> wrote: >> > Ick, hidi

Re: [PATCH] Allow userspace control of runtime disabling/enabling of driver probing

On Wed, Jan 4, 2017 at 1:46 PM, Greg Kroah-Hartman wrote: > On Wed, Jan 04, 2017 at 12:10:04PM -0600, Matthew Garrett wrote: >> On Wed, Jan 4, 2017 at 3:32 AM, Greg Kroah-Hartman >> wrote: >> > Ick, hiding this in the power management code? That's messy, and >> &g

Re: [PATCH] Allow userspace control of runtime disabling/enabling of driver probing

On Wed, Jan 4, 2017 at 12:10 PM, Matthew Garrett <mj...@coreos.com> wrote: > > The USB authentication feature was intended for handling wireless USB > devices - it can be reused for this, but the code isn't generic enough > to apply to other bus types. The two interact in exa

Re: [PATCH] Allow userspace control of runtime disabling/enabling of driver probing

On Wed, Jan 4, 2017 at 12:10 PM, Matthew Garrett wrote: > > The USB authentication feature was intended for handling wireless USB > devices - it can be reused for this, but the code isn't generic enough > to apply to other bus types. The two interact in exactly the way you'd

Re: [PATCH] Allow userspace to request device probing even if defer_all_probes is true

On Wed, Jan 4, 2017 at 3:13 AM, Greg Kroah-Hartman wrote: >> Add a force_probe sysfs node to each device, which if written will >> trigger a probe even if defer_all_probes is currently true. > > Why not just manually trigger the bind of the device? I don't >

Re: [PATCH] Allow userspace to request device probing even if defer_all_probes is true

On Wed, Jan 4, 2017 at 3:13 AM, Greg Kroah-Hartman wrote: >> Add a force_probe sysfs node to each device, which if written will >> trigger a probe even if defer_all_probes is currently true. > > Why not just manually trigger the bind of the device? I don't > understand the problem here that is

Re: [PATCH] Allow userspace control of runtime disabling/enabling of driver probing

On Wed, Jan 4, 2017 at 3:32 AM, Greg Kroah-Hartman wrote: > Ick, hiding this in the power management code? That's messy, and > complex, as Rafael pointed out. It's in code that's used in the power management layer, not in power management code. This is all in the

Re: [PATCH] Allow userspace control of runtime disabling/enabling of driver probing

On Wed, Jan 4, 2017 at 3:32 AM, Greg Kroah-Hartman wrote: > Ick, hiding this in the power management code? That's messy, and > complex, as Rafael pointed out. It's in code that's used in the power management layer, not in power management code. This is all in the driver core. > Turning on and

Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport)

On Fri, Dec 02, 2016 at 07:55:30AM +0100, Greg KH wrote: > On Fri, Dec 02, 2016 at 03:07:00AM +0000, 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 >

Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport)

On Fri, Dec 02, 2016 at 07:55:30AM +0100, Greg KH wrote: > On Fri, Dec 02, 2016 at 03:07:00AM +0000, 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 >

Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport)

et distributed to everyone. There's clearly demand, and Linus has been clear that features that are shipped by everyone should just go into mainline, so if there are *technical* objections then let's figure them out and otherwise just get this stuff merged. -- Matthew Garrett | mj...@srcf.ucam.org

Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport)

et distributed to everyone. There's clearly demand, and Linus has been clear that features that are shipped by everyone should just go into mainline, so if there are *technical* objections then let's figure them out and otherwise just get this stuff merged. -- Matthew Garrett | mj...@srcf.ucam.org

Re: [PATCH 4/6] efi: Get the secure boot status [ver #2]

On Wed, Nov 23, 2016 at 6:55 AM, David Howells wrote: > Mark Rutland wrote: >> > Actually, the two arches have a different interpretation on how to deal >> > with an error. Matthew Garrett's original x86 patch assumes that if we >> > get an error when

Re: [PATCH 4/6] efi: Get the secure boot status [ver #2]

On Wed, Nov 23, 2016 at 6:55 AM, David Howells wrote: > Mark Rutland wrote: >> > Actually, the two arches have a different interpretation on how to deal >> > with an error. Matthew Garrett's original x86 patch assumes that if we >> > get an error when trying to read SecureBoot and SetupMode

Re: [PATCH] pci: completely disable aspm if it's unsupported

On Wed, Nov 18, 2015 at 11:00 AM, Josef Bacik wrote: > It looks to me I'm doing what Matthew set out to do, only with a bigger > hammer ;). His patch still allowed the initialization of the ASPM stuff, > like setting up the clocks and such, but then made it so we couldn't change > the ASPM state

Re: [PATCH] pci: completely disable aspm if it's unsupported

On Wed, Nov 18, 2015 at 11:00 AM, Josef Bacik wrote: > It looks to me I'm doing what Matthew set out to do, only with a bigger > hammer ;). His patch still allowed the initialization of the ASPM stuff, > like setting up the clocks and such, but then made it so we couldn't change >

Re: [PATCH v3] tpm, tpm_tis: fix tpm_tis ACPI detection issue with TPM 2.0

On Thu, Oct 08, 2015 at 06:04:27PM +0300, Jarkko Sakkinen wrote: > Hi > > This would need Tested-by's. I've tested it both PTT/fTPM based system > and dTPM (2.0) based system. Thank you. I'm on the road at the moment, but I'll be able to test this next week. -- Matthew

Re: [PATCH v3] tpm, tpm_tis: fix tpm_tis ACPI detection issue with TPM 2.0

On Thu, Oct 08, 2015 at 06:04:27PM +0300, Jarkko Sakkinen wrote: > Hi > > This would need Tested-by's. I've tested it both PTT/fTPM based system > and dTPM (2.0) based system. Thank you. I'm on the road at the moment, but I'll be able to test this next week. -- Matthew

Re: [PATCH 1/2] tpm, tpm_tis: use acpi_driver instead of pnp_driver

ution would to have two tables and have only MSFT0101 > in tpm_acpi_tbl in order to make sure that old functionality is not > broken up because we want this also to the stable kernels. I'd agree here. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line

Re: [PATCH 1/2] tpm, tpm_tis: use acpi_driver instead of pnp_driver

Device Tree later on. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH 1/2] tpm, tpm_tis: use acpi_driver instead of pnp_driver

ution would to have two tables and have only MSFT0101 > in tpm_acpi_tbl in order to make sure that old functionality is not > broken up because we want this also to the stable kernels. I'd agree here. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line

Re: [PATCH 1/2] tpm, tpm_tis: use acpi_driver instead of pnp_driver

Device Tree later on. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH 1/2] tpm, tpm_tis: use acpi_driver instead of pnp_driver

On Tue, Sep 29, 2015 at 08:07:10PM +0300, Jarkko Sakkinen wrote: > Migrate to struct acpi_driver in order to get out of 7 character > limitation for the HID. Are we guaranteed that there are no old systems reporting these devices via pnpbios rather than acpi? -- Matthew Garret

Re: [PATCH 1/2] tpm, tpm_tis: use acpi_driver instead of pnp_driver

On Tue, Sep 29, 2015 at 08:07:10PM +0300, Jarkko Sakkinen wrote: > Migrate to struct acpi_driver in order to get out of 7 character > limitation for the HID. Are we guaranteed that there are no old systems reporting these devices via pnpbios rather than acpi? -- Matthew Garret

Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime

go... -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime

go... -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime

t we map everything completely 1:1 (VA = PA) and call the > setVA thing but pass it literally the identity. Last time I tried this I found that some firmware makes assumptions about having high addresses. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send t

Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime

> > Why can't we map everything completely 1:1 (VA = PA) and call the > setVA thing but pass it literally the identity. Last time I tried this I found that some firmware makes assumptions about having high addresses. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe fro

Re: [PATCH V2] x86: Allow built-in command line to work in early kernel init

On Wed, Jun 3, 2015 at 2:24 AM, Ingo Molnar wrote: > It's all pretty non-trivial, so it has to be finegrained, perfectly > bisectable, > etc. Yeah. I'm not really going to be able to justify the time for that - this is code that dates back a long way, there's undoubtedly subtleties throughout

Re: [PATCH V2] x86: Allow built-in command line to work in early kernel init

On Wed, Jun 3, 2015 at 2:24 AM, Ingo Molnar mi...@kernel.org wrote: It's all pretty non-trivial, so it has to be finegrained, perfectly bisectable, etc. Yeah. I'm not really going to be able to justify the time for that - this is code that dates back a long way, there's undoubtedly subtleties

Re: [PATCH V2] x86: Allow built-in command line to work in early kernel init

On Wed, May 20, 2015 at 12:42 AM, Ingo Molnar wrote: > * Matthew Garrett wrote: > Overall structure looks better now. > > One problem is that it's such a huge patch: is there a way to split > this up into smaller, more obvious, easier to bisect to patches? Ought to be possible.

Re: [PATCH V2] x86: Allow built-in command line to work in early kernel init

On Wed, May 20, 2015 at 12:42 AM, Ingo Molnar mi...@kernel.org wrote: * Matthew Garrett mj...@coreos.com wrote: Overall structure looks better now. One problem is that it's such a huge patch: is there a way to split this up into smaller, more obvious, easier to bisect to patches? Ought

Re: dell_rbtn - kernel panic at boot...

but I think merging them is probably the last bad answer. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-

Re: dell_rbtn - kernel panic at boot...

think merging them is probably the last bad answer. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read

[PATCH V2] x86: Allow built-in command line to work in early kernel init

more. Signed-off-by: Matthew Garrett --- Updated to allocate a buffer for the new command line - I'm not intimitely familiar with the 16-bit setup code, so I could do with some feedback on whether the heap it allocates is guaranteed to remain untouched until the actual kernel setup code has run

[PATCH V2] x86: Allow built-in command line to work in early kernel init

more. Signed-off-by: Matthew Garrett mj...@coreos.com --- Updated to allocate a buffer for the new command line - I'm not intimitely familiar with the 16-bit setup code, so I could do with some feedback on whether the heap it allocates is guaranteed to remain untouched until the actual kernel

Re: [PATCH V2] x86: Allow built-in command line to work in early kernel init

On Tue, May 12, 2015 at 07:46:11PM -0700, H. Peter Anvin wrote: > On 05/12/2015 04:53 PM, Matthew Garrett wrote: > > On Tue, May 12, 2015 at 04:41:22PM -0700, Yinghai Lu wrote: > > > >> You can not assume that you can use buffer after cmd_line from bootloader > >>

Re: [PATCH V2] x86: Allow built-in command line to work in early kernel init

On Tue, May 12, 2015 at 04:41:22PM -0700, Yinghai Lu wrote: > You can not assume that you can use buffer after cmd_line from bootloader > blindly. Are there any bootloaders that don't allocate a buffer of the maximum command line size? -- Matthew Garrett | mj...@srcf.uc

Re: [PATCH V2] x86: Allow built-in command line to work in early kernel init

e */ +status = efi_low_alloc(sys_table_arg, strlen(builtin_cmdline), + 0, _addr); +if (status != EFI_SUCCESS) +return NULL; +while (builtin_cmdline[i] && i < COMMAND_LINE_SIZE) { +((char *)cmdline_addr)[i] = builtin_cmdlin

Re: [PATCH V2] x86: Allow built-in command line to work in early kernel init

On Tue, May 12, 2015 at 2:28 AM, Ingo Molnar wrote: > > * Matthew Garrett wrote: > >> Any feedback on this? > > So I worry about: > > - the fragmented nature of it: lots of non-obvious pieces of code >will now be scattered all around arch/x86/. We've g

Re: [PATCH V2] x86: Allow built-in command line to work in early kernel init

On Tue, May 12, 2015 at 2:28 AM, Ingo Molnar mi...@kernel.org wrote: * Matthew Garrett matthew.garr...@coreos.com wrote: Any feedback on this? So I worry about: - the fragmented nature of it: lots of non-obvious pieces of code will now be scattered all around arch/x86/. We've got

Re: [PATCH V2] x86: Allow built-in command line to work in early kernel init

'; +*cmd_line_len = strlen(builtin_cmdline); +} -*cmd_line_len = options_bytes; return (char *)cmdline_addr; } -- Matthew Garrett | matthew.garr...@coreos.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org

Re: [PATCH V2] x86: Allow built-in command line to work in early kernel init

On Tue, May 12, 2015 at 04:41:22PM -0700, Yinghai Lu wrote: You can not assume that you can use buffer after cmd_line from bootloader blindly. Are there any bootloaders that don't allocate a buffer of the maximum command line size? -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe

Re: [PATCH V2] x86: Allow built-in command line to work in early kernel init

On Tue, May 12, 2015 at 07:46:11PM -0700, H. Peter Anvin wrote: On 05/12/2015 04:53 PM, Matthew Garrett wrote: On Tue, May 12, 2015 at 04:41:22PM -0700, Yinghai Lu wrote: You can not assume that you can use buffer after cmd_line from bootloader blindly. Are there any bootloaders

<    2   3   4   5   6   7   8   9   10   11   >