linux-kernel - Re: [PATCH v2] lkdtm/bugs: Don't expect thread termination without CONFIG_UBSAN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <202204131405.025EAE89@keescook>
Date:   Wed, 13 Apr 2022 14:20:48 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Konstantin Ryabitsev <konstantin@...uxfoundation.org>
Cc:     Christophe Leroy <christophe.leroy@...roup.eu>,
        Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [PATCH v2] lkdtm/bugs: Don't expect thread termination without
 CONFIG_UBSAN_TRAP

On Wed, Apr 13, 2022 at 05:01:31PM -0400, Konstantin Ryabitsev wrote:
> On Wed, Apr 13, 2022 at 06:29:36AM +0000, Christophe Leroy wrote:
> > I have a [patatt] section in .gitconfig which contains:
> > 	signingkey  = ed25519:xxxxxxxx
> > 	selector = xxxxxxxx (the same value as above)
> > 
> > What should I do now for you to get the key ? I don't even know where 
> > the key is stored in my computer.
> 
> Your key is stored in ~/.local/share/patatt, but you don't really need to do
> anything, Kees can do the following:
> 
>     b4 kr --show-keys 363b58690e907c677252467a94fe49444c80ea76.1649704381.git.christophe.leroy@...roup.eu

Ah-ha, excellent.

> 
> For now, this just provides instructions on what to do with the key:
> 
> 	christophe.leroy@...roup.eu: (unknown)
> 		keytype: ed25519
> 		 pubkey: HIzTzUj91asvincQGOFx6+ZF5AoUuP9GdOtQChs7Mm0=
> 		 krpath: ed25519/csgroup.eu/christophe.leroy/20211009
> 	   fullpath: /home/user/.local/share/b4/keyring/ed25519/csgroup.eu/christophe.leroy/20211009

"fullpath" seems misleading for my config, given:

[patatt]
	...
        keyringsrc = ~/korg/pgpkeys/.keyring

Shouldn't this report fullpath as:

	/home/kees/korg/pgpkeys/.keyring/ed25519/csgroup.eu/christophe.leroy/20211009

And as a side note, should I prefer .local/share/b4/keyring over adding
keys to a branch of the kernel keyring git tree?

> 	---
> 	For ed25519 keys:
> 		echo [pubkey] > [fullpath]
> 
> So, for Kees to start being aware of your key, he needs to do:
> 
> 	mkdir -p /home/user/.local/share/b4/keyring/ed25519/csgroup.eu/christophe.leroy
> 	echo HIzTzUj91asvincQGOFx6+ZF5AoUuP9GdOtQChs7Mm0= > /home/user/.local/share/b4/keyring/ed25519/csgroup.eu/christophe.leroy/20211009
> 
> I know this is awkward and clunky right now. Future versions of b4 will
> streamline keyring management to make it a lot easier, I promise.

Thanks for this walk-through! I think I managed this in the past with
another ed25519 key, but I failed to figure it out this time. ;)

Now it works! :)

  ✓ [PATCH v2] lkdtm/bugs: Don't expect thread termination without
CONFIG_UBSAN_TRAP
    + Signed-off-by: Kees Cook <keescook@...omium.org>
    + Link: https://lore.kernel.org/r/363b58690e907c677252467a94fe49444c80ea76.1649704381.git.christophe.leroy@csgroup.eu
  ---
  ✓ Signed: ed25519/christophe.leroy@...roup.eu


-- 
Kees Cook