<div dir="ltr"><div>So this still seems to be lingering as unresolved in my mind. I need to find out what the remaining reservations are on this feature. I am going to try and summarize...<br><br></div><div>Steve Grub:<br>
</div><div>1. Anyway to use argv values as cmdline could be a page (too big)<br></div><div>2. Doesn't like disappearing audit entries<br><br></div><div>Richard Briggs:<br></div><div>1. Can we make it dynamic on/off<br>
<br></div><div>Stephen Smalley:<br></div><div>1. Can we cache the data for performance reasons<br></div><div><br></div><div>So I addressed RGB's issues, which led to one of steve Grub's concerns. Which I can address both with if feature on then print cmdline=value else print cmdline=(null)</div>
<div><br></div><div>Unfortunately the data I want to audit, is the full proc/cmdline entry, which I think is the most<br></div><div>generic way of getting at potential vm data through various fork mazes on Android, as well<br>
as gathering the data on other architectures as well. This also prevents us from hitting the<br></div><div>16 char width issue on task->comm. Increasing that will result in more non-pageable kernel<br>memory use, versus my transient use of a page. I also need to make sure I can get this<br>
data before the process terminates, which can happen if I try to acquire it in user-space.<br></div><div><br></div><div>Also, on error conditions, the last patch version will not print cmdline=(null) which is an error and can be trivially corrected. <br>
<br>But before I put more time into it, I want to make sure the underlying idea will be accepted, architectures, cacheing, print formats etc are all trivial.<br></div><div><br></div><div><div><br>-- <br>Respectfully,<br><br>
William C Roberts<br><br>
</div></div></div>