netdev - Re: [PATCH][XFRM] export SAD info

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] [day] [month] [year] [list]

Message-Id: <1177683705.4059.29.camel@localhost>
Date:	Fri, 27 Apr 2007 10:21:45 -0400
From:	jamal <hadi@...erus.ca>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH][XFRM] export SAD info

On Thu, 2007-26-04 at 14:18 -0700, David Miller wrote:

> I wouldn't mind if it actually helped anything.
> 
> The SMP cache line transactions are more expensive than the
> execution of the code blocks they are protecting.  rwlock's
> rarely help, and when they do (the execution path is more
> expensive than the SMP atomic operations) then you're holding
> the lock too long :-)
> 

Ok ;->
So if i was to make any change, it would be for consistency
with SPD. If this is sufficiently compelling i will send a patch.

> I would prefer a dynamic algorithm that reacts to system memory
> pressure and yet-another-knob that people will get wrong and
> there is no sane default for.
> 

This would certainly be a better approach if doable.

> I plan to do away with all the GC threshold madness in the
> routing cache, for example, and just let the MM layer call
> back into us when there is memory pressure to trigger GC.
> 
> See set_shrinker() and friends.  The MM calls into these
> handlers in response to memory pressure.  There is no
> reason the networking can't hook into this and do things
> properly instead of the ad-hoc manner we currently use.

Scanning the kernel ... 
I wasnt aware of this, neat; not many areas in the kernel seem to use
it. I find this stuff interesting, so i may get too verbose ;->

One approach i tried was to write an oom_handler - but it seemed to
get invoked a little too late, i.e when shit has already hit the fan.
If only i could get notified just before swap kicks in or just when some
preconfigured (by me) memmory threshold is hit.... This may do it? I
will experiment. Actually for it to work well, I will need to know when
the memory threshold is crossed as it goes down and when it is going up
as more memory gets freed.

I can see the shrinker working well with dynamically createable 
entries (route cache, arp cache, contrack etc); shrinking a SAD, SPD,
FIB etc that was created by some user space app without user space
consent or at least notification may be unacceptable (imagine Quagga/BGP
adding FIB entries and the kernel deciding its gonna run out of mem and
starting to delete entries; worse deleting SAD entries may be a security
risk etc etc). My problem is more related to these sorts of user
controlled tables.  
One approach that may work to address the above is to send a signal to
user space when the low mem threshold is approaching.. User space then
uses that info to slow down its abuse of memory. I think that signaling
maybe achievable by a genlmsg being sent to a multicast group which a
user space app will have to subscribe to.
Another approach is to use the shrinker callback to set a lowmem
condition to start rejecting any new table additions. A timer to 
retry would take it back; a callback from the VM to say "you can go
ahead and alloc more now" would be better of course - i couldnt see this
anywhere in the VM code, but it is one of those subsystem i dont pay
attention to, it may be there.

Thoughts? ;->

cheers,
jamal

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html