| Message ID | 20240516003524.143243-1-kpsingh@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | Reduce overhead of LSMs with static calls | expand |
On 2024/05/16 9:35, KP Singh wrote: > Since we know the address of the enabled LSM callbacks at compile time and only > the order is determined at boot time, the LSM framework can allocate static > calls for each of the possible LSM callbacks and these calls can be updated once > the order is determined at boot. I don't like this assumption. None of built-in LSMs is used by (or affordable for) my customers. There is a reality that only out-of-tree security modules which the distributor (namely, Red Hat) cannot support (and therefore cannot be built into RHEL kernels) are used by (or affordable for) such customers. Therefore, without giving room for allowing such security modules to load after boot, I consider this change a regression.
On Thu, May 16, 2024 at 02:35:19AM +0200, KP Singh wrote: > This series is a respin of the RFC proposed by Paul Renauld (renauld@google.com) > and Brendan Jackman (jackmanb@google.com) [1] > > # Performance improvement > > With this patch-set some syscalls with lots of LSM hooks in their path > benefitted at an average of ~3% and I/O and Pipe based system calls benefitting > the most. Hi Paul, With the merge window closed now, can we please land this in -next so we can get any glitches found/hammered out with maximal time before the next merge window? -Kees
On Thu, Jun 6, 2024 at 11:58 AM Kees Cook <kees@kernel.org> wrote: > On Thu, May 16, 2024 at 02:35:19AM +0200, KP Singh wrote: > > This series is a respin of the RFC proposed by Paul Renauld (renauld@google.com) > > and Brendan Jackman (jackmanb@google.com) [1] > > > > # Performance improvement > > > > With this patch-set some syscalls with lots of LSM hooks in their path > > benefitted at an average of ~3% and I/O and Pipe based system calls benefitting > > the most. > > Hi Paul, > > With the merge window closed now, can we please land this in -next so we > can get any glitches found/hammered out with maximal time before the > next merge window? It's in the queue, I've been swamped lately as you'll likely notice I haven't really had a chance to process patches yet during this cycle. We've also been over this soo many times that I've lost count - you know this is on my list, I've mentioned it multiple times that this is now high on the todo list, and your continued nagging does nothing other than make me want to look at other patches first. You're not helping your cause Kees.
On Thu, Jun 06, 2024 at 12:36:03PM -0400, Paul Moore wrote: > It's in the queue, I've been swamped lately as you'll likely notice I > haven't really had a chance to process patches yet during this cycle. I get that you're busy, and I understand that situation -- I get swamped too. The latency on LSM patch review has been very high lately, and I'm hoping there's some way we could help. I assume other folks could jump in and help with the queue[1], but I'm not sure if that would satisfy your requirements? Other subsystems have been switching more and more to a group maintainership system, etc. Are there other people you'd be comfortable sharing the load with? (Currently James and Serge are also listed as "M:" in MAINTAINERS, but I don't think the 3 of you have a shared git.kernel.org tree, for example...) And yes, there are a lot of patches up for review. I'm antsy about this series in particular because I'm worried inaction is going to create larger problems for the LSM as a whole. We've already had Linus drop in and tell us to do better; I'd really like to avoid having him make unilateral changes to the LSM, especially when we have a solution on deck that has been reviewed by many people. I will go back to being anxious/patient... ;) -Kees [1] https://patchwork.kernel.org/project/linux-security-module/list/
On Thu, Jun 6, 2024 at 2:07 PM Kees Cook <kees@kernel.org> wrote: > On Thu, Jun 06, 2024 at 12:36:03PM -0400, Paul Moore wrote: > > It's in the queue, I've been swamped lately as you'll likely notice I > > haven't really had a chance to process patches yet during this cycle. > > I get that you're busy, and I understand that situation -- I get swamped > too. The latency on LSM patch review has been very high lately, and I'm > hoping there's some way we could help. I assume other folks could jump > in and help with the queue[1], but I'm not sure if that would satisfy > your requirements? Other subsystems have been switching more and more to > a group maintainership system, etc. Are there other people you'd be > comfortable sharing the load with? (Currently James and Serge are also > listed as "M:" in MAINTAINERS, but I don't think the 3 of you have a > shared git.kernel.org tree, for example...) We already have a fairly distributed model with each LSM sending directly to Linus; the issue we are seeing now is an odd combination of multiple things: 1) $DAYJOB has had a sudden explosion of high priority internal work which has siphoned away a good chunk of my time 2) we have seen an historically unusual amount of development at the LSM layer itself (as opposed to the individual LSMs) 3) we had a long holiday weekend here in the US and I decided to do what normal people do and not spend all weekend arguing with people on the Internet. Without going into details on #1, let's just say it is transient and not something I expect to be a long term issue (if it does become a long term issue I'll start looking for a new $DAYJOB). I suspect issue #2 is a byproduct of some of the efforts around reinvigorating LSM development, clearing up some long standing warts, etc. and also not something I expect to last for an extended period of time. Issue #3 is a direct result of ... well, far too many threads like this, both from well and poorly intentioned authors. As an aside, things like this typically work better if you have another email setup so you can do the good-cop/bad-cop bit more convincingly. > And yes, there are a lot of patches up for review. I'm antsy about this > series in particular because I'm worried inaction is going to create > larger problems for the LSM as a whole. We've already had Linus drop > in and tell us to do better; I'd really like to avoid having him make > unilateral changes to the LSM, especially when we have a solution on > deck that has been reviewed by many people. You'll note that I'm one of those "many people" that has reviewed it (and had my feedback ignored for several rounds). I simply haven't had the chance to review the latest revision. In my opinion the LSM's largest issue has nothing to do with code, and everything to do with the mentality that a hardware flaw is a LSM bug. If that same mentality wants to ignore decades of work, in a construct it insisted on, and break the user experience for billions of users (and entire usage scenarios) in order to satisfy some misdirected need, then I seriously doubt one patchset is going to solve anything. > I will go back to being anxious/patient... ;) "do better" ;)