On Mon, May 13, 2024 at 08:03:53AM -0600, James Bottomley wrote:
> On Mon, 2024-05-13 at 12:16 +0200, Samuel Ortiz wrote:
> > > However, it struck me you missed a third option: use the ima log
> > > format. This has the advantage that we can define additional
> > > events and have them published w
When asn1_encode_sequence() fails, WARN is not the correct solution.
1. asn1_encode_sequence() is not an internal function (located
in lib/asn1_encode.c).
2. Location is known, which makes the stack trace useless.
3. Results a crash if panic_on_warn is set.
It is also noteworthy that the use o
On Mon May 13, 2024 at 8:11 PM EEST, Ignat Korchagin wrote:
> On Fri, May 3, 2024 at 11:16 PM Ignat Korchagin wrote:
> I would like to point out to myself I was wrong: it is possible to ask
> the kernel to generate a trusted key inside the kernel locally with
> "keyctl add trusted kmk "new 32" @u"
On Mon, 2024-05-13 at 18:09 +0100, Ignat Korchagin wrote:
[...]
> TPM derived keys attempt to address the above use cases by allowing
> applications to deterministically derive unique cryptographic keys
> for their own purposes directly from the TPM seed in the owner
> hierarchy. The idea is that w
On Mon, May 13, 2024 at 03:10:24PM +0200, Roberto Sassu wrote:
> From: Roberto Sassu
>
> The UBSAN instrumentation cannot work in the vDSO since it is executing in
> userspace, so disable it in the Makefile. Fixes the build failures such as:
>
> CALLscripts/checksyscalls.sh
> VDSOarc
Error on asn1_encode_sequence() is handled with a WARN incorrectly
because:
1. asn1_encode_sequence() is not an internal function (located
in lib/asn1_encode.c).
2. Location on known, which makes the stack trace useless.
3. Results a crash if panic_on_warn is set.
It is also noteworthy that th
The pull request you sent on Thu, 9 May 2024 17:25:17 +0300:
> git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git
> tags/keys-next-6.10-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/25c73642cc5baea5b91bbb9b1f5fcd93672bfa08
Thank you!
--
Deet
The pull request you sent on Thu, 09 May 2024 23:04:04 +0300:
> git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git
> tags/tpmdd-next-6.10-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b19239143e393d4b52b3b9a17c7ac07138f2cfd4
Thank you!
--
Dee
The pull request you sent on Thu, 9 May 2024 18:47:51 +0300:
> git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git
> tags/keys-trusted-next-6.10-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c024814828f72b1ae9cc2c338997b2d9826c80f6
Thank you!
On Fri, May 3, 2024 at 11:16 PM Ignat Korchagin wrote:
>
> TPM derived keys get their payload from an HMAC primary key in the owner
> hierarchy mixed with some metadata from the requesting process.
>
> They are similar to trusted keys in the sense that the key security is rooted
> in the TPM, but
On Sat, May 4, 2024 at 5:35 PM Jarkko Sakkinen wrote:
>
> On Sat May 4, 2024 at 5:51 PM EEST, Jarkko Sakkinen wrote:
> > On Sat May 4, 2024 at 4:55 PM EEST, Ben Boeckel wrote:
> > > On Sat, May 04, 2024 at 03:21:11 +0300, Jarkko Sakkinen wrote:
> > > > I have no idea for what the key created with
On Mon, 2024-05-13 at 12:16 +0200, Samuel Ortiz wrote:
> On Fri, May 10, 2024 at 10:57:37PM -0400, James Bottomley wrote:
> > I'm not really sure where to hang this, since there's no posted
> > agenda
> > or materials for the CCC meeting today.
>
> The agenda was posted on the linux-coco ml [1]. I
On Mon, 2024-05-13 at 15:08 +0200, Johannes Berg wrote:
> On Mon, 2024-05-13 at 14:58 +0200, Roberto Sassu wrote:
> > On Mon, 2024-05-13 at 14:52 +0200, Johannes Berg wrote:
> > > On Mon, 2024-05-13 at 14:42 +0200, Roberto Sassu wrote:
> > > > On Mon, 2024-05-13 at 14:29 +0200, Johannes Berg wrote:
From: Roberto Sassu
The UBSAN instrumentation cannot work in the vDSO since it is executing in
userspace, so disable it in the Makefile. Fixes the build failures such as:
CALLscripts/checksyscalls.sh
VDSOarch/x86/um/vdso/vdso.so.dbg
arch/x86/um/vdso/vdso.so.dbg: undefined symbols fou
On Mon, 2024-05-13 at 14:58 +0200, Roberto Sassu wrote:
> On Mon, 2024-05-13 at 14:52 +0200, Johannes Berg wrote:
> > On Mon, 2024-05-13 at 14:42 +0200, Roberto Sassu wrote:
> > > On Mon, 2024-05-13 at 14:29 +0200, Johannes Berg wrote:
> > > > On Mon, 2024-05-13 at 14:27 +0200, Roberto Sassu wrote:
On Mon, 2024-05-13 at 14:52 +0200, Johannes Berg wrote:
> On Mon, 2024-05-13 at 14:42 +0200, Roberto Sassu wrote:
> > On Mon, 2024-05-13 at 14:29 +0200, Johannes Berg wrote:
> > > On Mon, 2024-05-13 at 14:27 +0200, Roberto Sassu wrote:
> > > > From: Roberto Sassu
> > > >
> > > > Disable UBSAN san
On Mon, 2024-05-13 at 14:42 +0200, Roberto Sassu wrote:
> On Mon, 2024-05-13 at 14:29 +0200, Johannes Berg wrote:
> > On Mon, 2024-05-13 at 14:27 +0200, Roberto Sassu wrote:
> > > From: Roberto Sassu
> > >
> > > Disable UBSAN sanitization on UML, since UML does not support it.
> > >
> >
> > Luc
On Mon, 2024-05-13 at 14:29 +0200, Johannes Berg wrote:
> On Mon, 2024-05-13 at 14:27 +0200, Roberto Sassu wrote:
> > From: Roberto Sassu
> >
> > Disable UBSAN sanitization on UML, since UML does not support it.
> >
>
> Luckily, that isn't actually true, nor does it actually do this at all.
> P
On Mon, 2024-05-13 at 14:27 +0200, Roberto Sassu wrote:
> From: Roberto Sassu
>
> Disable UBSAN sanitization on UML, since UML does not support it.
>
Luckily, that isn't actually true, nor does it actually do this at all.
Please fix the commit message.
johannes
From: Roberto Sassu
Disable UBSAN sanitization on UML, since UML does not support it.
This fixes the error message when building the kernel:
CALLscripts/checksyscalls.sh
VDSOarch/x86/um/vdso/vdso.so.dbg
arch/x86/um/vdso/vdso.so.dbg: undefined symbols found
Signed-off-by: Roberto Sa
On Fri, May 10, 2024 at 10:57:37PM -0400, James Bottomley wrote:
> I'm not really sure where to hang this, since there's no posted agenda
> or materials for the CCC meeting today.
The agenda was posted on the linux-coco ml [1]. I sent a link to the
presentation slides [2] to the thread.
> However
21 matches
Mail list logo