kib (Konstantin Belousov)
User

Projects

User Details

User Since
May 16 2014, 7:35 PM (157 w, 3 d)

Recent Activity

Today

kib committed rD50270: Document __FreeBSD_version 1200031..
Document __FreeBSD_version 1200031.
Tue, May 23, 10:11 AM
kib committed rS318739: For ld.so direct execution mode, implement -p option: search for the.
For ld.so direct execution mode, implement -p option: search for the
Tue, May 23, 10:01 AM
kib closed D10790: For ld.so direct execution mode, implement -p option: search for relative binary in $PATH. by committing rS318739: For ld.so direct execution mode, implement -p option: search for the.
Tue, May 23, 10:01 AM
kib committed rS318737: Regen..
Regen.
Tue, May 23, 9:31 AM
kib added a comment to D10799: lang/rust: Update for ino64.

Hi!

I started to think about this patch and I have some questions.

If I understand correctly, old_fstat.c is used to "patch" the rust-std bootstrap so that it calls the compatibility syscalls. Is that correct?

Yes.

Tue, May 23, 8:46 AM

Yesterday

kib updated the diff for D10826: Document direct execution mode for ld.so..

Handle emaste comments.

Mon, May 22, 10:44 AM
kib updated the diff for D10790: For ld.so direct execution mode, implement -p option: search for relative binary in $PATH..

Only activate -p if binary name does not contain '/' at all, not only if the patch is absolute. This is how execp(3) works.

Mon, May 22, 10:43 AM
kib added a comment to D10850: disallow open(2) in capability mode.

Sounds plausible, but I do wonder if the sysctl is currently a sufficient mature way to enable application development. Enabling it requires root, so it's not directly usable by end users on multiuser systems, and it also has global scope rather than just affecting applications that the developer is working on, which could change failure modes for a range of applications (such as desktop applications) that the developer has no interest in debugging and fixing. Is there some other mechanism we can add -- e.g., using ptrace(2) -- or setting an environmental variable that causes rtld to itself twiddle a per-process setting, that might offer a better real-world debugging experience?

Mon, May 22, 9:41 AM

Sun, May 21

kib accepted D10850: disallow open(2) in capability mode.
Sun, May 21, 11:03 PM
kib accepted D10843: move p_sigqueue to the end of struct proc.
Sun, May 21, 4:20 PM
kib added a comment to D10798: lang/ghc: Update for ino64.
In D10798#224628, @pgj wrote:

Okay, but I still do not understand something: is there a problem, and if yes, what is the problem with the way rebuilding the bootstrap compiler as I drafted above?

I think I understand what you are saying, but I do not get why this would cause any problems. I assumed that if you add those static compat shims to the current version of the bootstrap compiler libraries (like you are doing in the patch), then one is able to build a fully working version of GHC. To me, this seems to be sufficient to rebuild the bootstrap compiler from the sources that could be then used to replace the existing bootstrap for systems that are newer than a given __FreeBSD_version (post-ino64). Obviously, the old version of the bootstrap would be kept used for the older ones (pre-ino64), since the new version would not work there. You can see an example of that in some older version of the port's Makefile.

Sun, May 21, 12:34 PM
kib added a comment to D10798: lang/ghc: Update for ino64.
In D10798#224614, @pgj wrote:
In D10798#224610, @kib wrote:
It is due to the fact that runtime shipped with the bootstrap compiler, as well as installed by the port, are static, cause problem.

Are you sure of that?

Absolutely.

Sun, May 21, 11:42 AM
kib added a comment to D10798: lang/ghc: Update for ino64.
In D10798#224572, @pgj wrote:

I think building a new bootstrap becomes easy with this change.

Would ghc shipped with the dynamically-linked runtime, the change appeared to be not necessary. It is due to the fact that runtime shipped with the bootstrap compiler, as well as installed by the port, are static, cause problem. There is no mechanism to ensure ABI compatibility for the static libraries, nor it might appear in the future. On the other hand, we do (try to) maintain ABI backward compatbility for dynamic linking.

Sun, May 21, 8:51 AM

Sat, May 20

kib committed rS318576: MFC efivar(8) (by imp):.
MFC efivar(8) (by imp):
Sat, May 20, 4:13 PM
kib accepted D10832: libthr: use default WARNS level of 6, and fix warnings.
Sat, May 20, 3:52 PM
kib added inline comments to D10832: libthr: use default WARNS level of 6, and fix warnings.
Sat, May 20, 3:26 PM
kib added a comment to D10798: lang/ghc: Update for ino64.

Thank you for the prompt response.

Sat, May 20, 7:51 AM
kib committed rS318564: MFC r318256:.
MFC r318256:
Sat, May 20, 12:41 AM

Fri, May 19

kib updated the summary of D10826: Document direct execution mode for ld.so..
Fri, May 19, 11:21 PM
kib created D10826: Document direct execution mode for ld.so..
Fri, May 19, 11:21 PM
kib committed rS318529: MFC r318243:.
MFC r318243:
Fri, May 19, 10:17 AM
kib committed rS318528: MFC r318243:.
MFC r318243:
Fri, May 19, 9:04 AM
kib added a comment to D10808: Increase libthr WARNS to the default of 6, and fix the warnings.

Perhaps commit the changes which do not cause a discussion, now, to reduce the patch size.

Fri, May 19, 7:42 AM

Thu, May 18

kib added inline comments to D10797: lang/llvm40: Update for ino64.
Thu, May 18, 7:30 PM
kib added a comment to D10800: multimedia/webcamd: Update for ino64.

Linux defines dev_t like this, and I think webcamd wants to keep it 32-bit.

include/linux/types.h:typedef u32 kernel_dev_t;
include/linux/types.h:typedef __kernel_dev_t dev_t;

Is it impossible to have webcamd define its own dev_t due to the header file pollution made by the ino64 patch?

ino64 patch does not introduce any header pollution.

Thu, May 18, 5:13 PM
kib added a comment to D10800: multimedia/webcamd: Update for ino64.

dev_t is used in conjunction with MKDEV() which is 32-bit. Did you test if webcamd breaks w/o this patch or is this patch a simple result of "grep -r" ? The dev_t should not be used in any FreeBSD kernel interfaces, only Linux ones.

Thu, May 18, 4:41 PM
kib added a comment to D10795: devel/libgtop: Update for ino64.
In D10795#223708, @kwm wrote:

Ok, I will update it later with my patch when I get to doing my maintaince.

Sorry, it is not clear to me what should I do. Should I commit the patch from this review, and then you re-apply your preferred patch ? Or just delegate the port to you and presume that you will fix it shortly after ino64 src commit ?

Thu, May 18, 3:51 PM
kib added a comment to D10800: multimedia/webcamd: Update for ino64.

@kib

Is the patch written in a way that it can be used when the inode size is 32-bit ?

Or are ifdefs needed ?

Thu, May 18, 3:43 PM
kib added a comment to D10795: devel/libgtop: Update for ino64.
In D10795#223701, @kwm wrote:

I would prefer the patch for libgtop I added to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218320 to be committed instead. But this whole efford is a lot of work and I can always svn mv the patch later, and replace it with the one with __FreeBSD_version checks. I need to do maintainance on the port anyway, so it not that big of a deal to fix up the patch later.

I would like to thank you for providing the patch!

Thu, May 18, 3:40 PM
kib updated the diff for D10439: ino64.

Commit candidate.

Thu, May 18, 3:22 PM
kib created D10801: sysutils/py-psutil: Update for ino64.
Thu, May 18, 3:18 PM
kib created D10800: multimedia/webcamd: Update for ino64.
Thu, May 18, 3:16 PM
kib created D10799: lang/rust: Update for ino64.
Thu, May 18, 3:14 PM
kib created D10798: lang/ghc: Update for ino64.
Thu, May 18, 3:11 PM
kib created D10797: lang/llvm40: Update for ino64.
Thu, May 18, 3:08 PM
kib created D10796: lang/llvm39: Update for ino64.
Thu, May 18, 3:07 PM
kib created D10795: devel/libgtop: Update for ino64.
Thu, May 18, 3:04 PM
kib committed rS318450: Add tests for some cases in r318298..
Add tests for some cases in r318298.
Thu, May 18, 1:50 PM
kib created D10790: For ld.so direct execution mode, implement -p option: search for relative binary in $PATH..
Thu, May 18, 10:00 AM
kib committed rS318446: Update my copyright, note The FreeBSD Foundation involvement..
Update my copyright, note The FreeBSD Foundation involvement.
Thu, May 18, 9:34 AM
kib committed rS318445: Fix style [1], add static keyword before static function definition..
Fix style [1], add static keyword before static function definition.
Thu, May 18, 9:31 AM
kib added inline comments to D10773: makefs: Add soft-updates options.
Thu, May 18, 8:49 AM
kib added inline comments to D10778: [concurrency_kit] turn this into a module!.
Thu, May 18, 8:45 AM
kib added a comment to D10170: Capsicumize cpuset_*.

The two 'sysent' files should be done as a second commit, is that all that needs to be done?

Thu, May 18, 8:38 AM

Wed, May 17

kib accepted D10751: Allow rtld direct-exec to take a file descriptor..

For new functions in rtld, I use normal style(9), so rtld slowly migrates to proper indentation. For smaller changes to existing functions I do follow existing style of 4 spaces indent/2 spaces continuation.

Wed, May 17, 9:37 PM
kib added inline comments to D10751: Allow rtld direct-exec to take a file descriptor..
Wed, May 17, 9:10 PM
kib accepted D10435: x86: Add dynamic interrupt rebalancing.
Wed, May 17, 9:01 PM
kib added a comment to D10751: Allow rtld direct-exec to take a file descriptor..

Overall this looks good.

Wed, May 17, 5:08 PM
kib added inline comments to D10751: Allow rtld direct-exec to take a file descriptor..
Wed, May 17, 3:36 PM
kib added inline comments to D10773: makefs: Add soft-updates options.
Wed, May 17, 2:51 PM
kib added inline comments to D10751: Allow rtld direct-exec to take a file descriptor..
Wed, May 17, 1:29 PM
kib accepted D10729: Cleanup MD pollution of MI busdma header.

I gnerally like this simplification.

Wed, May 17, 12:44 PM

Tue, May 16

kib added inline comments to D10300: Correct bitwise test in mac_bsdextended ugidfw_rule_valid().
Tue, May 16, 9:41 PM
kib accepted D10758: Bump MAXTSIZ..

What about arm64 ?

Tue, May 16, 8:44 PM
kib closed D10750: Practice some security for the direct exec mode of ld.so. by committing rS318380: Pretend that there is some security when executing in direct mode..
Tue, May 16, 7:53 PM
kib committed rS318380: Pretend that there is some security when executing in direct mode..
Pretend that there is some security when executing in direct mode.
Tue, May 16, 7:53 PM
kib updated the diff for D10750: Practice some security for the direct exec mode of ld.so..

Update the message text.

Tue, May 16, 7:35 PM
kib added a comment to D4030: pmap_change_attr: Only fixup DMAP for DMAPed ranges.
In D4030#222841, @alc wrote:

Kostik, I didn't understand your last comment. Can you please elaborate?

Tue, May 16, 7:27 PM
kib updated the diff for D10750: Practice some security for the direct exec mode of ld.so..

Cover Ed notes.

Tue, May 16, 7:26 PM
kib added a reviewer for D10751: Allow rtld direct-exec to take a file descriptor.: emaste.
Tue, May 16, 2:24 PM
kib added a reviewer for D10750: Practice some security for the direct exec mode of ld.so.: jonathan.
Tue, May 16, 2:24 PM
kib added a comment to D10751: Allow rtld direct-exec to take a file descriptor..

Two small notes, this is not a review. Mostly to inform you about D10750.

Tue, May 16, 2:23 PM
kib accepted D10645: Avoid use of contiguous memory allocations in busdma.
Tue, May 16, 1:19 PM
kib added inline comments to D4030: pmap_change_attr: Only fixup DMAP for DMAPed ranges.
Tue, May 16, 1:17 PM
kib added a comment to D10751: Allow rtld direct-exec to take a file descriptor..

Were you thinking of getopt-style parsing (but without pulling in getopt) or environment variables (e.g., LD_BINARY_FD=xx)? The environment variable approach has the benefit of not requiring any new parsing code, but an explicit --fd xx will look more familiar. Then again, if we provide options people might come to expect --help and --usage options. :)

Tue, May 16, 12:49 PM
kib added a comment to D10751: Allow rtld direct-exec to take a file descriptor..

I do not like these argv0 tricks, I intend to implement normal options parsing for the direct mode. One of the options would take the file descriptor number and do what your trick does. I think that this is better than the trick since it allows to easily invoke and test the functionality from the shell.

Tue, May 16, 8:08 AM
kib added inline comments to D10750: Practice some security for the direct exec mode of ld.so..
Tue, May 16, 8:03 AM

Mon, May 15

kib created D10750: Practice some security for the direct exec mode of ld.so..
Mon, May 15, 10:11 PM
kib committed rS318318: Ensure that resume path on amd64 only accesses page tables for normal.
Ensure that resume path on amd64 only accesses page tables for normal
Mon, May 15, 8:53 PM
kib added inline comments to D10695: Enable shared page support on mips..
Mon, May 15, 7:38 PM
kib added a comment to D10689: procstat(1): Add TCP socket send/recv buffer size.
In D10689#222507, @cem wrote:
In D10689#222497, @kib wrote:

You need to regen syscall tables both in sys/kern and in sys/compat32. This is noted in /testing.txt.

I did try to do that. I may be invoking it wrong:

% make -C sys/kern syscalls
cc -O2 -pipe  syscalls.c  -o syscalls
/usr/lib/crt1.o: In function `_start':
/usr/src/lib/csu/amd64/crt1.c:(.text+0x17b): undefined reference to `main'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1
make -C sys/kern sysent
make -C sys/compat/freebsd32 sysent
Mon, May 15, 6:51 PM
kib committed rS318313: Make ld-elf.so.1 directly executable..
Make ld-elf.so.1 directly executable.
Mon, May 15, 6:49 PM
kib closed D10701: Make ld-elf.so.1 directly executable by committing rS318313: Make ld-elf.so.1 directly executable..
Mon, May 15, 6:49 PM
kib committed rS318312: Fix the AT_EXECFD functionality..
Fix the AT_EXECFD functionality.
Mon, May 15, 6:47 PM
kib added a comment to D10689: procstat(1): Add TCP socket send/recv buffer size.
In D10689#222486, @cem wrote:

Attempting to build test on ino64 branch runs into some failures apparently unrelated to this patch:

/home/cem/freebsd/sys/kern/kern_descrip.c:1309:43: error: declaration of 'struct freebsd11_fstat_args' will not be visible outside of this function [-Werror,-Wvisibility]
freebsd11_fstat(struct thread *td, struct freebsd11_fstat_args *uap)
                                          ^
Mon, May 15, 6:37 PM
kib committed rS318303: Style..
Style.
Mon, May 15, 5:54 PM
kib closed D10670: Simplify cleanup on failure in realpath(3). by committing rS318299: Simplify cleanup on failure in realpath(3)..
Mon, May 15, 5:34 PM
kib committed rS318299: Simplify cleanup on failure in realpath(3)..
Simplify cleanup on failure in realpath(3).
Mon, May 15, 5:34 PM
kib updated the diff for D10670: Simplify cleanup on failure in realpath(3)..

Update after merge with r318298.

Mon, May 15, 5:31 PM
kib committed rS318298: Fix several buffer overflows in realpath(3)..
Fix several buffer overflows in realpath(3).
Mon, May 15, 5:15 PM
kib updated the diff for D10701: Make ld-elf.so.1 directly executable.

s/0/NULL/

Mon, May 15, 3:21 PM
kib updated the diff for D10670: Simplify cleanup on failure in realpath(3)..

Do malloc() in realpath(), as before. Pass only 'resolved' to realpath1(), all logic to malloc and free is now located in realpath().

Mon, May 15, 3:19 PM
kib committed rS318285: mnt_vnode_next_active: use conventional lock order when trylock fails..
mnt_vnode_next_active: use conventional lock order when trylock fails.
Mon, May 15, 10:03 AM
kib closed D10692: mnt_vnode_next_active: use conventional lock order when trylock fails by committing rS318285: mnt_vnode_next_active: use conventional lock order when trylock fails..
Mon, May 15, 10:03 AM

Sun, May 14

kib added a comment to D9030: Create new fexecve() variant with explicit interpreter.
Sun, May 14, 1:16 PM
kib updated the diff for D10701: Make ld-elf.so.1 directly executable.

Move the shift before first getenv() call in the rtld, to not depend on details of getenv() implementation.
Do not forget to reset 'env' after environment is moved,not only environ (this caused env -i /libexec/ld-elf.so.1 /bin/ls segfault in jemalloc initializer).
Fix off-by-half in copying the auxv (this caused the assertion reported by Ed).

Sun, May 14, 12:36 PM
kib committed rS318267: MFC r317908:.
MFC r317908:
Sun, May 14, 12:00 PM
kib committed rS318266: MFC r317908:.
MFC r317908:
Sun, May 14, 11:51 AM

Sat, May 13

kib updated the diff for D10701: Make ld-elf.so.1 directly executable.

Update comment, remove stray space after copy.
Correct (remove) re-calculation of main_argv, it was shifted right too much.
Noted by emaste.

Sat, May 13, 8:07 PM
kib updated the diff for D10701: Make ld-elf.so.1 directly executable.

Re-merge after the locals reordering changes were committed.

Sat, May 13, 7:11 PM
kib committed rS318256: In _rtld(), reorder local declarations to compact the block and.
In _rtld(), reorder local declarations to compact the block and
Sat, May 13, 6:59 PM
kib added a comment to D10701: Make ld-elf.so.1 directly executable.
pooma% ls -l ~/build/bsd/DEV/stuff/tests/args
---x--x--x  1 kostik  kostik  6234 Apr 18  2010 /usr/home/kostik/build/bsd/DEV/stuff/tests/args
pooma% LD_LIBRARY_PATH=/usr/lib32 obj-i386/i386.i386/usr/home/kostik/work/build/bsd/DEV/src/libexec/rtld-elf/ld-elf.so.1 ~/build/bsd/DEV/stuff/tests/args 1 2 3
Fatal error

I.e. as expected, userspace needs to read executing binary.

Sat, May 13, 5:50 PM
kib updated the summary of D10701: Make ld-elf.so.1 directly executable.
Sat, May 13, 2:46 PM
kib created D10701: Make ld-elf.so.1 directly executable.
Sat, May 13, 2:45 PM
kib added a comment to D9030: Create new fexecve() variant with explicit interpreter.
In D9030#221740, @kib wrote:

Let's split two things. I thought that your issue at hand was the conflict between the nature of capability mode disallowing implicit root and absolute lookups, badly interfering with the typical absolute path specification for ELF interpreters.

Fair enough: that was, indeed, the original motivation. However, as soon as we start building more sophisticated compartments out of sandboxed-from-inception processes, I'm going to want to explore more interesting uses like the LLVM fat binary case (in which we will want a different linker from the one specified by ELF brandinfo). I see three mutually-compatible requirements:

  • must be able to execute dynamically-linked applications from capability mode,
  • must be able to choose a non-standard run-time linker and
  • should not require root privilege to do it.

    I think that an ffexecve(2) system call is a clean, fairly simple mechanism for supporting these and other requirements: it's a policy-agnostic mechanism that one might use to explore many different ideas in sandboxing. The approach that you suggested ("make kernel verify that the interpreter path in the binary PT_INTERP is equal to the ABI brandinfo interp_path and execute namei() for interp_path in non-cap mode") makes the ABI more complicated for non-expert developers to understand and also (this is the part that makes me nervous) deliberately violates Rule #1 of capability mode: no access to global namespaces.

My point is that ffexecve(2) -like syscall is not needed.

Sat, May 13, 12:23 PM
kib added a comment to D10695: Enable shared page support on mips..

The patch as-is is fine.

Sat, May 13, 11:45 AM
kib added a comment to D10692: mnt_vnode_next_active: use conventional lock order when trylock fails.

Peter, could you, please, test this change ? The interesting load is the same as was used for testing r244240, and the UP config is probably most important, but I do not expect surprises.

Sat, May 13, 11:35 AM
kib updated subscribers of D10692: mnt_vnode_next_active: use conventional lock order when trylock fails.
Sat, May 13, 11:33 AM

Fri, May 12

kib accepted D10692: mnt_vnode_next_active: use conventional lock order when trylock fails.
Fri, May 12, 9:30 PM
kib added inline comments to D10692: mnt_vnode_next_active: use conventional lock order when trylock fails.
Fri, May 12, 8:16 PM