linux-kernel - Re: [RFC v2 05/16] luo: luo

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: <mafs0sek3n0x8.fsf@kernel.org>
Date: Fri, 13 Jun 2025 16:58:27 +0200
From: Pratyush Yadav <pratyush@...nel.org>
To: Pasha Tatashin <pasha.tatashin@...een.com>
Cc: Pratyush Yadav <pratyush@...nel.org>,  jasonmiu@...gle.com,
  graf@...zon.com,  changyuanl@...gle.com,  rppt@...nel.org,
  dmatlack@...gle.com,  rientjes@...gle.com,  corbet@....net,
  rdunlap@...radead.org,  ilpo.jarvinen@...ux.intel.com,
  kanie@...ux.alibaba.com,  ojeda@...nel.org,  aliceryhl@...gle.com,
  masahiroy@...nel.org,  akpm@...ux-foundation.org,  tj@...nel.org,
  yoann.congal@...le.fr,  mmaurer@...gle.com,  roman.gushchin@...ux.dev,
  chenridong@...wei.com,  axboe@...nel.dk,  mark.rutland@....com,
  jannh@...gle.com,  vincent.guittot@...aro.org,  hannes@...xchg.org,
  dan.j.williams@...el.com,  david@...hat.com,  joel.granados@...nel.org,
  rostedt@...dmis.org,  anna.schumaker@...cle.com,  song@...nel.org,
  zhangguopeng@...inos.cn,  linux@...ssschuh.net,
  linux-kernel@...r.kernel.org,  linux-doc@...r.kernel.org,
  linux-mm@...ck.org,  gregkh@...uxfoundation.org,  tglx@...utronix.de,
  mingo@...hat.com,  bp@...en8.de,  dave.hansen@...ux.intel.com,
  x86@...nel.org,  hpa@...or.com,  rafael@...nel.org,  dakr@...nel.org,
  bartosz.golaszewski@...aro.org,  cw00.choi@...sung.com,
  myungjoo.ham@...sung.com,  yesanishhere@...il.com,
  Jonathan.Cameron@...wei.com,  quic_zijuhu@...cinc.com,
  aleksander.lobakin@...el.com,  ira.weiny@...el.com,
  andriy.shevchenko@...ux.intel.com,  leon@...nel.org,  lukas@...ner.de,
  bhelgaas@...gle.com,  wagi@...nel.org,  djeffery@...hat.com,
  stuart.w.hayes@...il.com
Subject: Re: [RFC v2 05/16] luo: luo_core: integrate with KHO

On Sat, Jun 07 2025, Pasha Tatashin wrote:
[...]
>>
>> This weirdness happens because luo_prepare() and luo_cancel() control
>> the KHO state machine, but then also get controlled by it via the
>> notifier callbacks. So the relationship between then is not clear.
>> __luo_prepare() at least needs access to struct kho_serialization, so it
>> needs to come from the callback. So I don't have a clear way to clean
>> this all up off the top of my head.
>
> On production machine, without KHO_DEBUGFS, only LUO can control KHO
> state, but if debugfs is enabled, KHO can be finalized manually, and
> in this case LUO transitions to prepared state. In both cases, the
> path is identical. The KHO debugfs path is only for
> developers/debugging purposes.

What I meant is that even without KHO_DEBUGFS, LUO drives KHO, but then
KHO calls into LUO from the notifier, which makes the control flow
somewhat convoluted. If LUO is supposed to be the only thing that
interacts directly with KHO, maybe we should get rid of the notifier and
only let LUO drive things.

This can be done later though; it doesn't have to be in the initial
revision.

>
>> >  static int __init luo_startup(void)
>> >  {
>> > -     __luo_set_state(LIVEUPDATE_STATE_NORMAL);
>> > +     phys_addr_t fdt_phys;
>> > +     int ret;
>> > +
>> > +     if (!kho_is_enabled()) {
>> > +             if (luo_enabled)
>> > +                     pr_warn("Disabling liveupdate because KHO is disabled\n");
>> > +             luo_enabled = false;
>> > +             return 0;
>> > +     }
>> > +
>> > +     ret = register_kho_notifier(&luo_kho_notifier_nb);
>> > +     if (ret) {
>> > +             luo_enabled = false;
>>
>> You set luo_enabled to false here, but none of the LUO entry points like
>> luo_prepare() or luo_freeze() actually check it. So LUO will appear work
>> just fine even when it hasn't initialized properly.
>
> luo_enabled check was missing from luo_ioctl.c, as we should not
> create a device if LUO is not enabled. This is fixed.
>
>>
>> > +             pr_warn("Failed to register with KHO [%d]\n", ret);
>>
>> I guess you don't return here so a previous liveupdate can still be
>> recovered, even though we won't be able to make the next one. If so, a
>> comment would be nice to point this out.
>
> This is correct, but this is not going to work. Because, with the
> current change I am disabling "/dev/liveupdate" iff luo_enable ==
> false. Let's just return here, failing to register with KHO should not
> really happen, it usually means that there is another notifier with
> the same name has already registered.

Okay, fair enough.

-- 
Regards,
Pratyush Yadav