Re: [RFC PATCH] security: Allow dropping bounding set process-wide

[Jinjie Ruan <ruanjinjie@huawei.com>]

在 2026/9/25 22:34, Serge E. Hallyn 写道:
> Jinjie, could you reproduce your timing experiments against the
> SetProc code?

Hi Serge, the test result is as below:

|   method      |   Description                                       |
| ------------- | --------------------------------------------------- |
| baseline	| Per-cap syscall.AllThreadsSyscall6(PR_CAPBSET_DROP),|
|               |   the original gVisor implementation                |
| dropbound	| libcap cap.DropBound() (library API, per-thread)    |
| SetProc	| cap.IABGetProc() + SetVector(Bound) + SetProc()     |
| SetProc-min	| Minimal IAB with the read overhead removed: NewIAB()|
|               |  + SetVector(Bound) + SetProc()                     |
| mask	        | prctl(PR_CAPBSET_DROP_MASK, lo, hi)                 |

All variants uniformly drop all 41 caps (cap_last_cap = 40), and both
the success rate and dropped are verified.

Sampling scale:
- Patched guest, 8 vCPU: 2 boots × 21 runs = 42 runs/point, 1050 samples
total;
- Patched guest, 32 vCPU: 21 runs per point, 525 samples total.

Mean in µs bucketed by actual thread count (sample count in parentheses)

## 8 vCPU (42 samples per point)

method	     8–15	16–31	      32–63	   64–95
baseline    3258.9(41)	6955.9(43)   10303.9(84)   14394.3(42)
dropbound   3356.3(41)	5048.1(43)   9914.3(84)	   16837.1(42)
SetProc	    3365.4(41)	6255.4(43)   10179.4(84)   16799.8(42)
SetProc-min 3485.0(41)	5603.9(43)   10533.2(84)   15146.8(42)
mask	    68.2(42)	92.3(42)     224.2(84)	   433.7(42)

## 32 vCPU (21 samples per point)

method	      8–15	 16–31	       32–63	      64–95
baseline     8422.4(20)	 8491.8(22)   17814.2(42)    21612.6(21)
dropbound    5235.5(21)	 7568.9(21)   17350.8(42)    21205.5(21)
SetProc	     5540.8(21)	 8159.2(21)   17920.5(42)    22168.3(21)
SetProc-min  5582.8(20)	 7907.7(22)   15136.0(42)    22334.5(21)
mask	     114.6(21)	 181.8(21)    428.5(42)      684.7(21)

So IAB.SetProc is not an optimization. Like the gVisor baseline, it
issues one PR_CAPBSET_DROP per capability on every thread
(syscall.AllThreadsSyscall); averaged over multiple repeated groups, it
is on the same order of magnitude as the baseline, or even slower.

> 
> On Tue, Sep 22, 2026 at 07:10:11PM -0700, Andrew G. Morgan wrote:
>> The https://pkg.go.dev/kernel.org/pub/linux/libs/security/libcap/cap#IAB.SetProc
>> already handles this for the whole process. It can be run from main()
>> if you need it to happen early, and it will track down all of the
>> threads in the runtime.
>>
>> To Serge's point, I am also curious what benefit there is from doing
>> it more quickly. After all, this is pretty much a one-time function
>> request for any executable.
>>
>> FYI The "sendmail capabilities bug" reference is written up here:
>> https://sites.google.com/site/fullycapable/thesendmailcapabilitiesissue
>>
>> Cheers
>>
>> Andrew
>>

[...]
>>>>       /*
>>>>        * The next four prctl's remain to assist with transitioning a
>>>>        * system from legacy UID=0 based privilege (when filesystem
>>>> --
>>>> 2.34.1

-- 
Best regards,
Jinjie