On Mon, 2024-11-18 at 10:43 -0800, Andy Lutomirski wrote:
> Linux should not use TPM2_PCR_Extend *at all*. Instead, Linux should
> exclusively use TPM2_PCR_Event. I would expect that passing, say,
> the entire kernel image to TPM2_PCR_Event would be a big mistake, so
> instead Linux should hash t
On Sat, 2024-11-02 at 10:53 -0400, Daniel P. Smith wrote:
> Hi Luto,
>
> My apologies, I missed this response and the active on v11 cause me
> to
> get an inquiry why I hadn't responded.
>
> On 9/21/24 18:40, Andy Lutomirski wrote:
[...]
> > I assumed that "deliberately cap" meant that there was
On Fri, 2024-09-13 at 13:05 -0700, Ross Philipson wrote:
> Expose a sysfs interface to allow user mode to set and query the
> default locality set for the TPM chip.
What does a user need this for? It somewhat conflicts with the idea of
running the kernel and user space TPM access in separate loca
On Sat, 2023-11-11 at 18:19 +, Andrew Cooper wrote:
> On 11/11/2023 5:44 pm, Eric Biggers wrote:
> > On Fri, Nov 10, 2023 at 05:27:44PM -0500, Ross Philipson wrote:
> > > arch/x86/boot/compressed/early_sha1.c | 12
> > > lib/crypto/sha1.c | 81
> > > +++
On Tue, 2020-09-15 at 08:27 +0200, Christoph Hellwig wrote:
> On Mon, Sep 14, 2020 at 08:20:18AM -0700, James Bottomley wrote:
> > If you're going to change the macros from taking a device to taking
> > a hostdata structure then the descriptive argument name needs to
> >
On Mon, 2020-09-14 at 16:44 +0200, Christoph Hellwig wrote:
> @@ -429,7 +430,7 @@ struct NCR_700_Host_Parameters {
> for(i=0; i< (sizeof(A_##symbol##_used) / sizeof(__u32));
> i++) { \
> __u32 val =
> bS_to_cpu((script)[A_##symbol##_used[i]]) + da; \
> (script)[A_#
On Tue, 2020-09-01 at 16:05 +0100, Matthew Wilcox wrote:
> On Tue, Sep 01, 2020 at 07:52:40AM -0700, James Bottomley wrote:
> > I think this looks mostly OK, except for one misnamed parameter
> > below. Unfortunately, the last non-coherent parisc was the 700
> > series and
On Wed, 2020-08-19 at 08:55 +0200, Christoph Hellwig wrote:
> Switch the 53c700 driver to only use non-coherent descriptor memory
> if it really has to because dma_alloc_coherent fails. This doesn't
> matter for any of the platforms it runs on currently, but that will
> change soon.
>
> To help w
On Thu, 2019-08-08 at 19:00 +0300, Christoph Hellwig wrote:
> parisc is the only architecture that sets ARCH_NO_COHERENT_DMA_MMAP
> when an MMU is enabled. AFAIK this is because parisc CPUs use VIVT
> caches,
We're actually VIPT but the same principle applies.
> which means exporting normally c
On Mon, 2015-09-28 at 14:50 +, David Laight wrote:
> From: James Bottomley [mailto:james.bottom...@hansenpartnership.com]
> > Sent: 28 September 2015 15:27
> > On Mon, 2015-09-28 at 08:58 +, David Laight wrote:
> > > From: Rafael J. Wysocki
> > >
On Mon, 2015-09-28 at 08:58 +, David Laight wrote:
> From: Rafael J. Wysocki
> > Sent: 27 September 2015 15:09
> ...
> > > > Say you have three adjacent fields in a structure, x, y, z, each one
> > > > byte long.
> > > > Initially, all of them are equal to 0.
> > > >
> > > > CPU A writes 1 to
On Fri, 2015-09-25 at 22:58 +0200, Rafael J. Wysocki wrote:
> On Friday, September 25, 2015 01:25:49 PM Viresh Kumar wrote:
> > On 25 September 2015 at 13:33, Rafael J. Wysocki wrote:
> > > You're going to change that into bool in the next patch, right?
> >
> > Yeah.
> >
> > > So what if bool is
Your subject line is very tame. It should be the one line summary of
why we apply the patch, so it should read something like
hpsa: fix NULL deref in performant mode
On Thu, 2014-04-10 at 17:17 -0500, scame...@beardog.cce.hp.com wrote:
> Without this, you'll see a null pointer dereference in
>
On Mon, 2012-09-24 at 12:04 +0300, Hiroshi Doyu wrote:
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index a1a7225..9eae3be 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -21,6 +21,8 @@
> #include
> #include
>
> +#include
> +
> #include "base
14 matches
Mail list logo
