Vdso - Revision history

Dsafonov: a bit specify what's structure of vdso

2019-07-31T19:21:01Z

a bit specify what's structure of vdso

Radostin: /* A problem */

2018-08-26T07:47:16Z

A problem

Xemul at 16:38, 23 January 2015

2015-01-23T16:38:05Z

Cyrillos at 08:06, 14 January 2015

2015-01-14T08:06:19Z

Cyrillos at 08:04, 14 January 2015

2015-01-14T08:04:46Z

Cyrillos at 20:22, 13 January 2015

2015-01-13T20:22:29Z

Cyrillos: Created page with "draft"

2015-01-13T19:52:37Z

Created page with "draft"

New page

draft

@@ Line 11: / Line 11: @@
 To solve this problem CRIU does that named call proxification, where all functions from the original '''vDSO''' code are redirected to a new one provided by the kernel where application is restored. This done in a several steps on restore:
-# Scan runtime environment for current '''vDSO''' and parse its structure
+# Scan runtime environment for current '''vDSO''' and parse its structure (size, sections, symbols, etc)
 # On restore of dumped '''vDSO''' memory area we patch function entry points so that they are redirected to current '''vDSO''' (for x86 architecture is simply a <code>jmp</code> instruction)
@@ Line 17: / Line 17: @@
 In case if an application is dumped and restored on same kernel CRIU detects that '''vDSO''' structure has not be changed and doesn't use calls proxification.
 [[Category: Under the hood]]

@@ Line 5: / Line 5: @@
 === A problem ===
-While kernel guarantees backwards compatibility, i.e. helper functions won't suddenly disappear, the internal structure of the '''vDSO''' itself may vary the way it wants, userspace programs won't notice such changes but it brings a huge problem to CRIU. The '''vDSO''' structure is highly coupled with the kernel internals so that if application is migrating to a new kernel release with brand new '''vDSO''' old one (which is still sitting in application memory) strictly speaking is no longer usable, because the new kernel implies new '''vDSO''' internal structure.
+While the kernel guarantees backwards compatibility (i.e. helper functions won't suddenly disappear), the internal structure of the '''vDSO''' itself may vary. Userspace programs won't notice such changes but it brings a huge problem to CRIU. The '''vDSO''' structure is highly coupled with the kernel internals. If an application is being migrated to a new kernel release (with a brand new '''vDSO''') the old '''vDSO''' (which is stored in the application's memory) is no longer usable.
 === Calls proxification ===

← Older revision		Revision as of 16:38, 23 January 2015
Line 17:		Line 17:

	In case if an application is dumped and restored on same kernel CRIU detects that '''vDSO''' structure has not be changed and doesn't use calls proxification.		In case if an application is dumped and restored on same kernel CRIU detects that '''vDSO''' structure has not be changed and doesn't use calls proxification.
		+
		+	[[Category: Under the hood]]

← Older revision		Revision as of 08:06, 14 January 2015
Line 15:		Line 15:

	After that an restored application can continue using original '''vDSO''' helpers without problems.		After that an restored application can continue using original '''vDSO''' helpers without problems.
		+
		+	In case if an application is dumped and restored on same kernel CRIU detects that '''vDSO''' structure has not be changed and doesn't use calls proxification.

@@ Line 1: / Line 1: @@
 === Overview ===
-'''vDSO''' stands for [http://man7.org/linux/man-pages/man7/vdso.7.html ''virtual dynamic shared object''] and basically is a shared library exported by kernel into every userspace program. It usually export the following helper functions: gettimeofday, time, getcpu, clock_gettime. Userspace applications don't call them directly but make use of '''libc''' instead.
+'''vDSO''' stands for [http://man7.org/linux/man-pages/man7/vdso.7.html ''virtual dynamic shared object''] and basically is a shared library exported by kernel into every userspace program. It usually exports a few frequently used functions (such as gettimeofday, getcpu and etc) and userspace applications don't call them directly but make use of '''libc''' instead.
 === A problem ===
-While kernel guarantees backwards compatibility, i.e. these helpers won't suddenly disappear, the internal structure of the '''vDSO''' itself may vary the way it wants, userspace programs won't notice such changes but this make a huge problem for CRIU. The '''vDSO''' is a part of userspace application and its structure highly coupled with kernel internals.
+While kernel guarantees backwards compatibility, i.e. helper functions won't suddenly disappear, the internal structure of the '''vDSO''' itself may vary the way it wants, userspace programs won't notice such changes but it brings a huge problem to CRIU. The '''vDSO''' structure is highly coupled with the kernel internals so that if application is migrating to a new kernel release with brand new '''vDSO''' old one (which is still sitting in application memory) strictly speaking is no longer usable, because the new kernel implies new '''vDSO''' internal structure.

← Older revision		Revision as of 20:22, 13 January 2015
Line 1:		Line 1:
−	~~draft~~	+	=== Overview ===
		+
		+	'''vDSO''' stands for [http://man7.org/linux/man-pages/man7/vdso.7.html ''virtual dynamic shared object''] and basically is a shared library exported by kernel into every userspace program. It usually export the following helper functions: gettimeofday, time, getcpu, clock_gettime. Userspace applications don't call them directly but make use of '''libc''' instead.
		+
		+	=== A problem ===
		+
		+	While kernel guarantees backwards compatibility, i.e. these helpers won't suddenly disappear, the internal structure of the '''vDSO''' itself may vary the way it wants, userspace programs won't notice such changes but this make a huge problem for CRIU. The '''vDSO''' is a part of userspace application and its structure highly coupled with kernel internals.