If /system partition is never encrypted (even in “full-disk” encryption), how is it protected?

It seems that Android’s “full-disk-encrytpion” is only concerned about encrypting the data or internal storage partition. It says:

Full-disk encryption is the process of encoding all user data on an Android device using an encrypted key. Once a device is encrypted, all user-created data is automatically encrypted before committing it to disk and all reads automatically decrypt data before returning it to the calling process.

I am puzzled what encryption (at rest) of user-data is worth, if an attacker can simply modify the content of the /system partition, to contain a malware that would exfiltrate data or encryption key.

Is there a reason to consider Android’s encryption to be effective even though /system partition is not encrypted?

I assume that an answer involves a chain-of-trust, relative to a locked boot loader.

My python code is not returning anything even when there are no blockages inside the function, upon function call

Here is my code:

class Solution:     def searchInsert(self, nums, target):         """         :type nums: List[int]         :type target: int         :rtype: int         """         flag = 0         mid = int(len(nums)/2)         if (target == nums[mid]):             print("entered here") #             flag = 1             return 100         if ((target<nums[mid]) and(mid > 0)):             self.searchInsert(nums[:mid], target)         if ((target>nums[mid]) and (mid < (len(nums)-1))):             self.searchInsert(nums[mid :], target) 

Considering the search value has to be in the array, when I run this I get no return value

s = [1,3,5,6] v = 6 ret = Solution().searchInsert(s,v) 

My output to this is: entered here

Why is my code not returning 100 when it is right next to the print statement which is being executed?

Java application gets killed in kubernetes even the resource limits and heap size are specified

Background

A spring boot Java application is deployed in a kubernetes cluster and gets killed several times per day.

I’m using openjdk:8u181-jre for my Java apps.

Kubernetes version: v1.11.5

Node os: CentOS 7.4 x64

JAVA_OPTS are set according to this post about letting java application read the cgroup limitations. https://developers.redhat.com/blog/2017/03/14/java-inside-docker/

env: - name: JAVA_OPTS   value: " -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -XX:MaxRAMFraction=2 -Xms512M" resources:   requests:     memory: "4096Mi"     cpu: "1"   limits:     memory: "4096Mi"     cpu: "1" 

The nodes in the cluster are with memory of 16GiB. And the pod is requesting 4GiB.

Error

But the application get OOM killed from time to time.

The system events:

Jan 16 23:29:58 localhost kernel: java invoked oom-killer: gfp_mask=0xd0, order=0, oom_score_adj=-998 Jan 16 23:29:58 localhost kernel: java cpuset=docker-aa640424ab783e441cbd26cd25b7817e5a36deff2f44b369153d7399020d1059.scope mems_allowed=0 Jan 16 23:29:58 localhost kernel: CPU: 7 PID: 19904 Comm: java Tainted: G           OE  ------------ T 3.10.0-693.2.2.el7.x86_64 #1 Jan 16 23:29:58 localhost kernel: Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 Jan 16 23:29:58 localhost kernel: ffff880362700000 000000008b5adefc ffff88034078bc90 ffffffff816a3db1 Jan 16 23:29:58 localhost kernel: ffff88034078bd20 ffffffff8169f1a6 ffff8803b1642680 0000000000000001 Jan 16 23:29:58 localhost kernel: 0000000000000000 ffff880407eeaad0 ffff88034078bcd0 0000000000000046 Jan 16 23:29:58 localhost kernel: Call Trace: Jan 16 23:29:58 localhost kernel: [<ffffffff816a3db1>] dump_stack+0x19/0x1b Jan 16 23:29:58 localhost kernel: [<ffffffff8169f1a6>] dump_header+0x90/0x229 Jan 16 23:29:58 localhost kernel: [<ffffffff81185ee6>] ? find_lock_task_mm+0x56/0xc0 Jan 16 23:29:58 localhost kernel: [<ffffffff81186394>] oom_kill_process+0x254/0x3d0 Jan 16 23:29:58 localhost kernel: [<ffffffff811f52a6>] mem_cgroup_oom_synchronize+0x546/0x570 Jan 16 23:29:58 localhost kernel: [<ffffffff811f4720>] ? mem_cgroup_charge_common+0xc0/0xc0 Jan 16 23:29:58 localhost kernel: [<ffffffff81186c24>] pagefault_out_of_memory+0x14/0x90 Jan 16 23:29:58 localhost kernel: [<ffffffff8169d56e>] mm_fault_error+0x68/0x12b Jan 16 23:29:58 localhost kernel: [<ffffffff816b0231>] __do_page_fault+0x391/0x450 Jan 16 23:29:58 localhost kernel: [<ffffffff810295da>] ? __switch_to+0x15a/0x510 Jan 16 23:29:58 localhost kernel: [<ffffffff816b03d6>] trace_do_page_fault+0x56/0x150 Jan 16 23:29:58 localhost kernel: [<ffffffff816afa6a>] do_async_page_fault+0x1a/0xd0 Jan 16 23:29:58 localhost kernel: [<ffffffff816ac578>] async_page_fault+0x28/0x30 Jan 16 23:29:58 localhost kernel: Task in /kubepods.slice/kubepods-podc4e5c355_196b_11e9_b6ba_00163e066499.slice/docker-aa640424ab783e441cbd26cd25b7817e5a36deff2f44b369153d7399020d1059.scope killed as a result of limit of /kubepods.slice/kubepods-podc4e5c355_196b_11e9_b6ba_00163e066499.slice Jan 16 23:29:58 localhost kernel: memory: usage 4194304kB, limit 4194304kB, failcnt 7722 Jan 16 23:29:58 localhost kernel: memory+swap: usage 4194304kB, limit 9007199254740988kB, failcnt 0 Jan 16 23:29:58 localhost kernel: kmem: usage 0kB, limit 9007199254740988kB, failcnt 0 Jan 16 23:29:58 localhost kernel: Memory cgroup stats for /kubepods.slice/kubepods-podc4e5c355_196b_11e9_b6ba_00163e066499.slice: cache:0KB rss:0KB rss_huge:0KB mapped_file:0KB swap:0KB inactive_anon:0KB active_anon:0KB inactive_file:0KB active_file:0KB unevictable:0KB Jan 16 23:29:58 localhost kernel: Memory cgroup stats for /kubepods.slice/kubepods-podc4e5c355_196b_11e9_b6ba_00163e066499.slice/docker-58ff049ead2b1713e8a6c736b4637b64f8b6b5c9d1232101792b4d1e8cf03d6a.scope: cache:0KB rss:40KB rss_huge:0KB mapped_file:0KB swap:0KB inactive_anon:0KB active_anon:40KB inactive_file:0KB active_file:0KB unevictable:0KB Jan 16 23:29:58 localhost kernel: Memory cgroup stats for /kubepods.slice/kubepods-podc4e5c355_196b_11e9_b6ba_00163e066499.slice/docker-aa640424ab783e441cbd26cd25b7817e5a36deff2f44b369153d7399020d1059.scope: cache:32KB rss:4194232KB rss_huge:3786752KB mapped_file:8KB swap:0KB inactive_anon:0KB active_anon:4194232KB inactive_file:0KB active_file:32KB unevictable:0KB Jan 16 23:29:58 localhost kernel: [ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name Jan 16 23:29:58 localhost kernel: [19357]     0 19357      254        1       4        0          -998 pause Jan 16 23:29:58 localhost kernel: [19485]     0 19485     1071      161       7        0          -998 sh Jan 16 23:29:58 localhost kernel: [19497]     0 19497  2008713  1051013    2203        0          -998 java Jan 16 23:29:58 localhost kernel: Memory cgroup out of memory: Kill process 31404 (java) score 6 or sacrifice child Jan 16 23:29:58 localhost kernel: Killed process 19497 (java) total-vm:8034852kB, anon-rss:4188424kB, file-rss:15628kB, shmem-rss:0kB 

I’m quite confused that the Heap size should be limited to 2GiB (estimated) since the RAMFactor is set to 2. But the container is got killed. 🙁

Could you please help me to find out a correct way or method to dig into this error?

I’m not sure how to answer this and I don’t even know what type of math it is

I’m studying for a finals about probability distribution with Z-table and I got to this part in the example of my lecturer and I have no idea how she arrived to this answer, I’ve been staring at it and scratching my head for a good 30 minutes and still don’t know how she got it.

-2.33 = h-172/8 h = 153.4 

How did she get 153.4?

LIDAR burnout; standards, specifications, or even guidelines for thermal damage due to infrared lasers?

The BBC News article Driverless car laser ruined camera describes a situation where a particularly powerful infrared laser from the LIDAR of a prototype car at the CES show damaged the sensor of a photogrpher’s camera.

Question: Are there any standards, specifications, or even guidelines anywhere in the sensor or camera manufacturing industries for thermal damage due to intense sources of light?

  • If a LIDAR manufacturer wanted to be responsible and build a system that they could say probably will not damage security cameras and traffic cameras up and down the street, is there any place they could turn for information or limits on laser emission? Perhaps a maximum radiance value in each of several wavelength ranges?

  • Or if a camera manufacturer wanted to be responsible and build a camera that they could say probably will not be damaged by car, robot, or other LIDAR systems?

  • Or if a LIDAR were part of a display of another product (like a car or robot) but it may not be obvious to every member of the public that there were IR lasers involved, and the display owners wanted to know what laser level might warrant them including a warning about cameras?

So far, answers to the question Are there industry standards or specs for image sensor resistance to damage from intense light? Ask Question are basically “no”, but outdoor photography is so ubiquitous that there’s plenty of experience.

Now however, eye-level infrared laser beams are something new and different, and these are invisible and so one doesn’t necessarily know one is photographing a laser until the dot shows up in the photo.

If I understand correctly these LIDAR systems use wavelengths that are absorbed in the front of the eye and so never pass through the lens and get focused to a small spot on the retina. An IR-blocking filter on the lens can mitigate the problem, but an IR-blocking filter on the sensor, near the focus, can melt and fail for the obvious reason that it absorbs the power which is now focused to a small spot.

enter image description here

Jit Ray Chowdhury/BBC

The lidar system on the top of the demonstration car

enter image description here

Jit Ray Chowdhury/BBC

The purple dots and lines on this photo of the Stratosphere hotel in Las Vegas show the damage…

The article goes on to explain:

Lidar works in a similar way to radar and sonar, using lasers rather than radio or soundwaves, explained Zeina Nazer, a postgraduate researcher at the University of Southampton specialising in driverless car technology.

“Powerful lasers can damage cameras,” she said.

“Camera sensors are, in general, more susceptible to damage than the human eye from lasers. Consumers are usually warned never to point a camera directly at laser emitters during a laser show.”

Ms Nazer added that for cameras to be immune to high power laser beams, they need an optical filter that cuts out infrared which is invisible to humans. However, it can affect night vision, when infrared can be an advantage.

AEye is known for its lidar units with much longer range than their competitors, ranging 1km compared to 200m or 300m,” she said.

“In my opinion, AEye should not use their powerful fibre laser during shows.”