You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

560 lines
24 KiB

  1. in the following i'll assume that you have good knowledge of i386
  2. protected mode details and some concepts about how modern OSs make
  3. use of them and i'll only explain what linux (2.6 in particular)
  4. does and how UDEREF modifies it to achieve best-effort (read: not
  5. perfect) userland/kernel separation.
  6. ----------------------------------------------------------------------------
  7. of the basic protected mode resources (TSS, GDT, LDT, IDT) we'll
  8. look at the GDT only as that's what defines all the interesting
  9. descriptors/segments needed for UDEREF (userland has some control
  10. over the per-process LDT but whatever is there isn't relevant as
  11. linux will load GDT selectors upon a userland->kernel transition
  12. and will never dereference anything in the LDT).
  13. linux 2.6 has per-CPU GDTs, each initialized from cpu_gdt_table
  14. in arch/i386/kernel/head.S . the kernel uses 3 descriptors there,
  15. __KERNEL_CS for %cs, __KERNEL_DS for %ss and __USER_DS for %ds/%es
  16. (since 2.6.20 there's a per-CPU data segment stored in %gs and in
  17. 2.6.21 it'll move into %fs, but it's not relevant for UDEREF).
  18. of these, __KERNEL_* are DPL=0 (i.e., for kernel use only), however
  19. __USER_DS is DPL=3, the default userland data selector loaded for
  20. any new userland process as well.
  21. all of these descriptors define a flat segment (0-4GB), so there's
  22. no userland/kernel separation at the segmentation level, it's
  23. solely up to the paging logic (i guess you already know why that's
  24. bad, but see below). the reason that the kernel uses the default
  25. userland data selectors/segments is that presumably there's some
  26. performance gain when the CPU reloads a segment register with the
  27. same value it already has (coming from a typical ELF process the
  28. data selectors will already have __USER_DS in them). i never checked
  29. this claim and maybe i misremember it, but in any case, regardless
  30. of which __*_DS selector the kernel uses, they're all flat anyway.
  31. now we're getting to the actual topic ;-). the problem i set out to
  32. solve with UDEREF was that many kernel bugs can be exploited (at all
  33. or more reliably) due to the fact that on i386 most OSs don't separate
  34. the userland virtual address space from that of the kernel. this in
  35. turn means that whenever userland can make the kernel (unexpectedly)
  36. dereference a userland controlled pointer, userland can control the
  37. data (and sometimes, control) flow of the kernel by virtue of providing
  38. the attack data in its own userland address range as it's fully visible
  39. in the kernel's virtual address space as well (the two virtual address
  40. spaces are the same because of the use of flat segments and lack of
  41. effective address space IDs in the i386 paging logic).
  42. since there're two stages in logical->physical address translation,
  43. one can attack the problem at each level. one approach is to make
  44. use of paging by realizing that %cr3 is effectively the address space
  45. ID on i386. that is, one can switch (reload) %cr3 on every kernel
  46. entry to point to page tables that simply don't map userland. this
  47. approach has been tried on linux in the so-called 4:4 VM patches
  48. (Red Hat, Ingo Molnar) and was used/offered in some RHEL series (it
  49. wasn't for security per se, but to provide a 4GB effective userland
  50. virtual address space for aging 32-bit machines with lots of memory).
  51. it has one big problem: performance impact. so much that it wasn't
  52. even on the table for me.
  53. the other approach is to make use of segmentation, which is what i
  54. do in UDEREF. the basic idea is very simple and very old, i first
  55. saw it in use (don't laugh ;-) on windows 95 where this particular
  56. feature caught NULL userland derefs in win32 processes (and prevented
  57. them from trashing the low DOS related memory). the trick they used
  58. was that they set up the userland segments as so-called expand-down
  59. segments, that is, the limit field in the segment descriptor meant
  60. the lowest valid address for the segment, so they could set it to
  61. something low, i forget the exact number now, but it was either 4MB
  62. or 4k.
  63. the same trick is used in UDEREF with a few more modifications. the
  64. new segment setup is as follows:
  65. kernel %cs:
  66. still __KERNEL_CS which remains flat (there's another PaX feature
  67. which limits it properly, but let's not digress)
  68. kernel %ss/%ds/%es:
  69. all switched to __KERNEL_DS which is no longer flat but turned
  70. into an expand-down segment with a lower limit set at the top of
  71. the userland address space (__PAGE_OFFSET in linux, normally it's
  72. at 3GB)
  73. userland %cs: stays the same __USER_CS, flat, doesn't matter
  74. userland %ds/%es/%ss:
  75. stays as __USER_DS but limited (most of the time) to the userland
  76. address space size.
  77. this setup so far is enough to cause a GPF whenever the kernel tries
  78. to dereference a pointer value that falls into the userland virtual
  79. address range (say, 0-3GB, i.e., NULL pointers are automatically
  80. included). what it's not enough for is the need to allow data transfer
  81. between userland/kernel and kernel/kernel in certain contexts. let's
  82. see them one by one.
  83. as you know, syscalls often need to copy data to/from userland which
  84. on i386 is most often implemented by the (rep) movs insn. this insn
  85. uses two data segments, one for the source, one for the destination
  86. (former can be overridden). this blind movs works in the usual case
  87. because all segments are flat, so data can freely move between kernel
  88. and userland virtual addresses.
  89. with the above described setup however we have a problem since
  90. neither %ds nor %es allow userland access. furthermore, even if one
  91. could override the source segment (so that one could use one of the
  92. remaining segment registers for copying from userland), it wouldn't
  93. help with copying to userland. the solution is that in these special
  94. copy functions (on linux it's all in asm) we reload the proper segment
  95. register with __USER_DS for the duration of the copy therefore we allow
  96. the copy to succeed *and* at the same time not allow kernel addresses
  97. where they're not expected (e.g., when the kernel copies from userland,
  98. this won't allow a source pointer to kernel land and vice versa).
  99. we're still not done however, as there's a special kernel/kernel copy
  100. problem (i don't know if it's specific to linux): certain internal
  101. kernel functions call syscall functions more or less directly (say,
  102. setting up a kernel thread or even just starting init makes use of
  103. the fork interface). this among others means that any normal userland
  104. pointer input these syscall expect will fall into the kernel address
  105. range - and would fail input validation right at the beginning, were
  106. it not for a trick linux uses: set_fs().
  107. there's some history behind this function because in early days linux
  108. actually used to be more secure in this regard as it used segmentation
  109. logic for userland/kernel separation (yes, there's some irony of fate
  110. here ;-) and it provided this set_fs() call to tell the kernel that
  111. further userland/kernel memory copy operations will actually stay within
  112. the kernel. many years later this interface was effectively switched off
  113. because linux turned to flat segments (the baby went with the bathwater
  114. or something like that) however one of its features stayed: the address
  115. space limit check in the low level copying functions. this limit check
  116. simply compared the to-be-dereferenced pointer against the current
  117. address space limit allowed for such copying (set_fs() itself was reduced
  118. to change only this limit as needed).
  119. with the non-flat segment setup described above we would still pass the
  120. address space limit check because it's not directly derived from the
  121. GDT descriptor limit but a per-thread variable, however we would fail
  122. the actual copy because one of the segment registers is reloaded with
  123. __USER_DS and that won't allow kernel addresses. the assumption i broke
  124. is that the separately maintained address space limit corresponds to
  125. the actual segment limit therefore the fix has to be that somehow this
  126. segment limit needs to be updated every time set_fs() is called.
  127. this can be accomplished by either updating the limit on __USER_DS (so
  128. that the actual copy functions don't have to change) or by loading either
  129. __USER_DS or __KERNEL_DS in said copy functions (then each one of them
  130. has to be patched for this).
  131. i went with the former for two reasons. one, it's a lot less code/work to
  132. update the (per-CPU) GDT descriptor vs. changing all the copy functions
  133. to conditonally load either __USER_DS or __KERNEL_DS (it took some time
  134. to find most/all such copy code, besides the obvious copy_{to/from}_user
  135. functions linux has a special IP checksumming code used for both kernel
  136. and userland buffers, then there were some direct userland address accesses
  137. in reboot code (to patch BIOS variables), etc).
  138. two, i wasn't actually sure that set_fs() is only ever called for
  139. kernel/kernel copy situatons (since it only raises the allowed address
  140. space limit, therefore on i386 it'd still allow userland accesses), so
  141. doing the 'conditional load in the copy code' stuff just to find out it
  142. was in vain wasn't worth it. i still want to try it out though because
  143. this is the reason i called the current approach 'best-effort' separation
  144. only: in set_fs() context a kernel bug has actually free reign over
  145. pointers in the copy functions (yes, it's still a lot smaller attack
  146. surface but i'm a maximalist ;-).
  147. so, as a summary: UDEREF makes sure that (data) segments for userland and
  148. the kernel are properly limited, either upwards (userland) or downwards
  149. (kernel). furthermore, every userland/kernel copy code is patched to use
  150. the proper segments for the inter-segment copy (the challenging part was
  151. to find all such code ;-). as a linux specialty, some care is taken to
  152. ensure that the same copy code works for kernel/kernel copying as well.
  153. note that GDT patching can be done safely because linux 2.6 has per-CPU
  154. GDTs (and in the context switch code i take care of the __USER_DS limit
  155. based on the set_fs() limit), on linux 2.4 and earlier this cannot be
  156. done (there's one shared GDT only) and there all the copy functions are
  157. potential escape points.
  158. ----------------------------------------------------------------------------
  159. that'd be it in a nutshell, feel free to ask me if you have questions.
  160. cheers,
  161. PaX Team
  162. To: pageexec@freemail.hu
  163. Cc: Elad Efrat
  164. Subject: Re: PaX uderef
  165. Date: Wed, 4 Apr 2007 15:14:45 +0900 (JST)
  166. From: [censored]
  167. > On 3 Apr 2007 at 20:28, Elad Efrat wrote:
  168. >
  169. > > [censored],
  170. > >
  171. > > I've cc'd the PaX author to this mail so he can elaborate on what uderef
  172. > > is, how it works, and why it was introduced.
  173. >
  174. > hello guys,
  175. >
  176. > in the following i'll assume that you have good knowledge of i386
  177. > protected mode details and some concepts about how modern OSs make
  178. > use of them and i'll only explain what linux (2.6 in particular)
  179. > does and how UDEREF modifies it to achieve best-effort (read: not
  180. > perfect) userland/kernel separation.
  181. thanks for explanation.
  182. > there's some history behind this function because in early days linux
  183. > actually used to be more secure in this regard as it used segmentation
  184. > logic for userland/kernel separation (yes, there's some irony of fate
  185. > here ;-) and it provided this set_fs() call to tell the kernel that
  186. > further userland/kernel memory copy operations will actually stay within
  187. > the kernel. many years later this interface was effectively switched off
  188. > because linux turned to flat segments (the baby went with the bathwater
  189. > or something like that) however one of its features stayed: the address
  190. > space limit check in the low level copying functions. this limit check
  191. > simply compared the to-be-dereferenced pointer against the current
  192. > address space limit allowed for such copying (set_fs() itself was reduced
  193. > to change only this limit as needed).
  194. loading selectors is rather expensive operation.
  195. well, it might be cheaper than reloading of cr3,
  196. but it's still something i (and linux folks i guess) don't want to do
  197. on every copying to/from userspace.
  198. do you have some numbers of the performance penalty?
  199. > note that GDT patching can be done safely because linux 2.6 has per-CPU
  200. > GDTs (and in the context switch code i take care of the __USER_DS limit
  201. > based on the set_fs() limit), on linux 2.4 and earlier this cannot be
  202. > done (there's one shared GDT only) and there all the copy functions are
  203. > potential escape points.
  204. what happens when you slept at some point after set_fs(), and woke up
  205. on another cpu?
  206. [censored]
  207. From: pageexec@freemail.hu
  208. To: [censored]
  209. Date: Wed, 04 Apr 2007 11:21:52 +0200
  210. Subject: Re: PaX uderef
  211. Reply-to: pageexec@freemail.hu
  212. CC: Elad Efrat
  213. On 4 Apr 2007 at 15:14, [censored] wrote:
  214. > loading selectors is rather expensive operation.
  215. > well, it might be cheaper than reloading of cr3,
  216. the cr3 reload approach is a lot slower not only because it flushes
  217. the TLBs on every user/kernel transition, but because it also has to
  218. handle the very same user/kernel copy situation: due to the address
  219. space switch, userland virtual addresses are no longer directly
  220. accessible and require special mappings to be set up for the duration
  221. of the copy. that means TLB entry invalidations which is one of the
  222. slowest operations of the CPU.
  223. > but it's still something i (and linux folks i guess) don't want to do
  224. > on every copying to/from userspace.
  225. > do you have some numbers of the performance penalty?
  226. i don't have micro-benchmarks on these functions per se, only the
  227. usual kernbench which didn't show any measurable impact (which is
  228. to be expected as it is not heavy on user/kernel copying, most time
  229. is spent in userland and the most used syscalls that do such copying
  230. are already expensive enough that any impact from UDEREF would
  231. disappear in the noise). if you have an idea for which syscall to
  232. exercise for this (i.e., something that spends most of its time in
  233. copying), let me know.
  234. > > note that GDT patching can be done safely because linux 2.6 has per-CPU
  235. > > GDTs (and in the context switch code i take care of the __USER_DS limit
  236. > > based on the set_fs() limit), on linux 2.4 and earlier this cannot be
  237. > > done (there's one shared GDT only) and there all the copy functions are
  238. > > potential escape points.
  239. >
  240. > what happens when you slept at some point after set_fs(), and woke up
  241. > on another cpu?
  242. both sleeping and waking up result in a context switch on each
  243. affected CPU (a call to __switch_to() in particular), therefore
  244. as i stated, the changes i made to that function ensure that the
  245. limit of __USER_DS of the given CPU's GDT will be updated to
  246. reflect the address space limit of the incoming thread (the limit
  247. of __USER_DS becomes part of the thread's state information as it
  248. now faithfully follows the already existing thread_info->addr_limit
  249. set by set_fs() - you can think of UDEREF as hardware enforcement
  250. of set_fs(), among others).
  251. To: pageexec@freemail.hu
  252. Cc: Elad Efrat
  253. Subject: Re: PaX uderef
  254. Date: Wed, 4 Apr 2007 18:53:18 +0900 (JST)
  255. From: [censored]
  256. > if you have an idea for which syscall to
  257. > exercise for this (i.e., something that spends most of its time in
  258. > copying), let me know.
  259. getresuid?
  260. > > > note that GDT patching can be done safely because linux 2.6 has per-CPU
  261. > > > GDTs (and in the context switch code i take care of the __USER_DS limit
  262. > > > based on the set_fs() limit), on linux 2.4 and earlier this cannot be
  263. > > > done (there's one shared GDT only) and there all the copy functions are
  264. > > > potential escape points.
  265. > >
  266. > > what happens when you slept at some point after set_fs(), and woke up
  267. > > on another cpu?
  268. >
  269. > both sleeping and waking up result in a context switch on each
  270. > affected CPU (a call to __switch_to() in particular), therefore
  271. > as i stated, the changes i made to that function ensure that the
  272. > limit of __USER_DS of the given CPU's GDT will be updated to
  273. > reflect the address space limit of the incoming thread (the limit
  274. > of __USER_DS becomes part of the thread's state information as it
  275. > now faithfully follows the already existing thread_info->addr_limit
  276. > set by set_fs() - you can think of UDEREF as hardware enforcement
  277. > of set_fs(), among others).
  278. ok, i have missed "in the context switch code ..." in your
  279. explanation. thanks.
  280. [censored]
  281. From: pageexec@freemail.hu
  282. To: [censored]
  283. Date: Sun, 08 Apr 2007 18:40:19 +0200
  284. Subject: Re: PaX uderef
  285. CC: Elad Efrat
  286. On 4 Apr 2007 at 18:53, [censored] wrote:
  287. > > if you have an idea for which syscall to
  288. > > exercise for this (i.e., something that spends most of its time in
  289. > > copying), let me know.
  290. >
  291. > getresuid?
  292. sorry for the delay but i didn't have a native linux install and just
  293. quickly put it on a new laptop. the box has a T7200 (core2/2GHz) with
  294. 2GB of RAM. the test was a simple looping around getresuid() with valid
  295. pointer arguments, 10 million times (everything was compiled with gentoo's
  296. gcc 4.1.1). i tested the following kernels:
  297. 1. 2.6.17-gentoo-r7 (from the gentoo 2006.1 livecd)
  298. real 0m1.440s 0m1.421s 0m1.422s 0m1.415s 0m1.426s 0m1.425s 0m1.424s
  299. 0m1.421s
  300. user 0m0.700s 0m0.680s 0m0.800s 0m0.670s 0m0.750s 0m0.740s 0m0.690s
  301. 0m0.750s
  302. sys 0m0.720s 0m0.740s 0m0.620s 0m0.750s 0m0.670s 0m0.690s 0m0.730s
  303. 0m0.670s
  304. 2. 2.6.21-rc6 (latest on kernel.org, without PARAVIRT)
  305. real 0m1.477s 0m1.471s 0m1.466s 0m1.466s 0m1.428s 0m1.471s 0m1.416s
  306. 0m1.466s
  307. user 0m0.808s 0m0.876s 0m0.784s 0m0.792s 0m0.704s 0m0.960s 0m0.668s
  308. 0m0.752s
  309. sys 0m0.648s 0m0.596s 0m0.680s 0m0.676s 0m0.724s 0m0.512s 0m0.748s
  310. 0m0.712s
  311. 3. 2.6.21-rc6 (latest on kernel.org, with PARAVIRT)
  312. real 0m3.277s 0m3.258s 0m3.258s 0m3.268s 0m3.258s 0m3.268s 0m3.258s
  313. 0m3.258s
  314. user 0m1.840s 0m1.884s 0m1.868s 0m2.000s 0m1.840s 0m2.040s 0m1.828s
  315. 0m1.756s
  316. sys 0m1.416s 0m1.376s 0m1.388s 0m1.268s 0m1.416s 0m1.228s 0m1.428s
  317. 0m1.500s
  318. 4. 2.6.21-rc6-pax (not public yet, without PARAVIRT, no PaX enabled)
  319. real 0m1.976s 0m1.949s 0m1.948s 0m1.928s 0m1.949s 0m1.948s 0m1.949s
  320. 0m1.948s
  321. user 0m0.868s 0m0.864s 0m0.972s 0m0.716s 0m0.896s 0m0.848s 0m0.824s
  322. 0m0.780s
  323. sys 0m1.080s 0m1.084s 0m0.976s 0m1.212s 0m1.052s 0m1.100s 0m1.124s
  324. 0m1.168s
  325. 5. 2.6.21-rc6-pax (not public yet, without PARAVIRT, with UDEREF)
  326. real 0m2.038s 0m2.029s 0m2.030s 0m1.991s 0m2.025s 0m1.991s 0m2.030s
  327. 0m2.029s
  328. user 0m0.880s 0m0.940s 0m0.824s 0m0.728s 0m0.784s 0m0.864s 0m0.796s
  329. 0m0.752s
  330. sys 0m1.148s 0m1.088s 0m1.204s 0m1.264s 0m1.240s 0m1.124s 0m1.236s
  331. 0m1.276s
  332. 6. 2.6.21-rc6-pax (not public yet, with PARAVIRT, with UDEREF)
  333. real 0m3.696s 0m3.685s 0m3.685s 0m3.686s 0m3.719s 0m3.690s 0m3.700s
  334. 0m3.696s
  335. user 0m1.952s 0m1.936s 0m1.844s 0m1.832s 0m1.804s 0m1.632s 0m1.816s
  336. 0m1.892s
  337. sys 0m1.732s 0m1.748s 0m1.840s 0m1.852s 0m1.912s 0m2.056s 0m1.880s
  338. 0m1.800s
  339. some notes:
  340. - the difference between 1. and 2. is probably due to some .config option
  341. (e.g., i enabled syscall auditing myself)
  342. - 2. and 3. show the effect of PARAVIRT (not that i wanted to test it
  343. per se but i accidentally left it enabled in PaX first so i reran
  344. everything twice ;P)
  345. - 3. and 4. show that some PaX features are not controlled by .config,
  346. among others the core part of UDEREF (segment reloads and overrides
  347. on the userland accessors) is always 'on'
  348. - 4. and 5. show that actually enabling UDEREF (changing the __USER_DS
  349. limit) has a small impact over just 4. alone (i.e., segment register
  350. reloads and overrides), so there seems to be some credence to the theory
  351. that the speed of segment reloads does depend on the actual descriptor
  352. content
  353. To: pageexec@freemail.hu
  354. Cc: Elad Efrat
  355. Subject: Re: PaX uderef
  356. Date: Tue, 10 Apr 2007 17:49:33 +0900 (JST)
  357. From: [censored]
  358. hi,
  359. > On 4 Apr 2007 at 18:53, [censored] wrote:
  360. >
  361. > > > if you have an idea for which syscall to
  362. > > > exercise for this (i.e., something that spends most of its time in
  363. > > > copying), let me know.
  364. > >
  365. > > getresuid?
  366. >
  367. > sorry for the delay but i didn't have a native linux install and just
  368. > quickly put it on a new laptop. the box has a T7200 (core2/2GHz) with
  369. > 2GB of RAM. the test was a simple looping around getresuid() with valid
  370. > pointer arguments, 10 million times (everything was compiled with gentoo's
  371. > gcc 4.1.1). i tested the following kernels:
  372. >
  373. > 1. 2.6.17-gentoo-r7 (from the gentoo 2006.1 livecd)
  374. > real 0m1.440s 0m1.421s 0m1.422s 0m1.415s 0m1.426s 0m1.425s 0m1.424s
  375. > 0m1.421s
  376. > user 0m0.700s 0m0.680s 0m0.800s 0m0.670s 0m0.750s 0m0.740s 0m0.690s
  377. > 0m0.750s
  378. > sys 0m0.720s 0m0.740s 0m0.620s 0m0.750s 0m0.670s 0m0.690s 0m0.730s
  379. > 0m0.670s
  380. does these columns mean you ran the same test 8 times?
  381. > 2. 2.6.21-rc6 (latest on kernel.org, without PARAVIRT)
  382. > real 0m1.477s 0m1.471s 0m1.466s 0m1.466s 0m1.428s 0m1.471s 0m1.416s
  383. > 0m1.466s
  384. > user 0m0.808s 0m0.876s 0m0.784s 0m0.792s 0m0.704s 0m0.960s 0m0.668s
  385. > 0m0.752s
  386. > sys 0m0.648s 0m0.596s 0m0.680s 0m0.676s 0m0.724s 0m0.512s 0m0.748s
  387. > 0m0.712s
  388. >
  389. > 3. 2.6.21-rc6 (latest on kernel.org, with PARAVIRT)
  390. > real 0m3.277s 0m3.258s 0m3.258s 0m3.268s 0m3.258s 0m3.268s 0m3.258s
  391. > 0m3.258s
  392. > user 0m1.840s 0m1.884s 0m1.868s 0m2.000s 0m1.840s 0m2.040s 0m1.828s
  393. > 0m1.756s
  394. > sys 0m1.416s 0m1.376s 0m1.388s 0m1.268s 0m1.416s 0m1.228s 0m1.428s
  395. > 0m1.500s
  396. >
  397. > 4. 2.6.21-rc6-pax (not public yet, without PARAVIRT, no PaX enabled)
  398. > real 0m1.976s 0m1.949s 0m1.948s 0m1.928s 0m1.949s 0m1.948s 0m1.949s
  399. > 0m1.948s
  400. > user 0m0.868s 0m0.864s 0m0.972s 0m0.716s 0m0.896s 0m0.848s 0m0.824s
  401. > 0m0.780s
  402. > sys 0m1.080s 0m1.084s 0m0.976s 0m1.212s 0m1.052s 0m1.100s 0m1.124s
  403. > 0m1.168s
  404. >
  405. > 5. 2.6.21-rc6-pax (not public yet, without PARAVIRT, with UDEREF)
  406. > real 0m2.038s 0m2.029s 0m2.030s 0m1.991s 0m2.025s 0m1.991s 0m2.030s
  407. > 0m2.029s
  408. > user 0m0.880s 0m0.940s 0m0.824s 0m0.728s 0m0.784s 0m0.864s 0m0.796s
  409. > 0m0.752s
  410. > sys 0m1.148s 0m1.088s 0m1.204s 0m1.264s 0m1.240s 0m1.124s 0m1.236s
  411. > 0m1.276s
  412. >
  413. > 6. 2.6.21-rc6-pax (not public yet, with PARAVIRT, with UDEREF)
  414. > real 0m3.696s 0m3.685s 0m3.685s 0m3.686s 0m3.719s 0m3.690s 0m3.700s
  415. > 0m3.696s
  416. > user 0m1.952s 0m1.936s 0m1.844s 0m1.832s 0m1.804s 0m1.632s 0m1.816s
  417. > 0m1.892s
  418. > sys 0m1.732s 0m1.748s 0m1.840s 0m1.852s 0m1.912s 0m2.056s 0m1.880s
  419. > 0m1.800s
  420. >
  421. > some notes:
  422. >
  423. > - the difference between 1. and 2. is probably due to some .config option
  424. > (e.g., i enabled syscall auditing myself)
  425. >
  426. > - 2. and 3. show the effect of PARAVIRT (not that i wanted to test it
  427. > per se but i accidentally left it enabled in PaX first so i reran
  428. > everything twice ;P)
  429. i wonder why it affects user time..
  430. > - 3. and 4. show that some PaX features are not controlled by .config,
  431. > among others the core part of UDEREF (segment reloads and overrides
  432. > on the userland accessors) is always 'on'
  433. 2. and 4. ?
  434. > - 4. and 5. show that actually enabling UDEREF (changing the __USER_DS
  435. > limit) has a small impact over just 4. alone (i.e., segment register
  436. > reloads and overrides), so there seems to be some credence to the theory
  437. > that the speed of segment reloads does depend on the actual descriptor
  438. > content
  439. hm, interesting.
  440. thanks for the info.
  441. [censored]
  442. From: pageexec@freemail.hu
  443. To: [censored]
  444. Date: Tue, 10 Apr 2007 11:42:49 +0200
  445. Subject: Re: PaX uderef
  446. CC: Elad Efrat
  447. On 10 Apr 2007 at 17:49, [censored] wrote:
  448. > > 1. 2.6.17-gentoo-r7 (from the gentoo 2006.1 livecd)
  449. > > real 0m1.440s 0m1.421s 0m1.422s 0m1.415s 0m1.426s 0m1.425s 0m1.424s
  450. > > 0m1.421s
  451. > > user 0m0.700s 0m0.680s 0m0.800s 0m0.670s 0m0.750s 0m0.740s 0m0.690s
  452. > > 0m0.750s
  453. > > sys 0m0.720s 0m0.740s 0m0.620s 0m0.750s 0m0.670s 0m0.690s 0m0.730s
  454. > > 0m0.670s
  455. >
  456. > does these columns mean you ran the same test 8 times?
  457. yes, each column is one run of 'time ./test', i thought it'd be easier
  458. to compare the times when arranged this way.
  459. > > - 2. and 3. show the effect of PARAVIRT (not that i wanted to test it
  460. > > per se but i accidentally left it enabled in PaX first so i reran
  461. > > everything twice ;P)
  462. >
  463. > i wonder why it affects user time..
  464. my only guess is that PARAVIRT disables the vdso (by default, and i didn't
  465. explicitly enable it) so that has an effect on the syscall itself (int 80h
  466. vs. sysenter).
  467. > > - 3. and 4. show that some PaX features are not controlled by .config,
  468. > > among others the core part of UDEREF (segment reloads and overrides
  469. > > on the userland accessors) is always 'on'
  470. >
  471. > 2. and 4. ?
  472. yes i meant those indeed.