Re: [PATCH 07/24] arm64: ilp32: add documentation on the ILP32 ABI for ARM64

[Pavel Machek]

On Wed 2018-05-16 11:18:52, Yury Norov wrote:
> Based on Andrew Pinski's patch-series.
> 
> Signed-off-by: Yury Norov 

So Andrew's signoff should be here?

> ---
>  Documentation/arm64/ilp32.txt | 45 +++
>  1 file changed, 45 insertions(+)
>  create mode 100644 Documentation/arm64/ilp32.txt
> 
> diff --git a/Documentation/arm64/ilp32.txt b/Documentation/arm64/ilp32.txt
> new file mode 100644
> index ..d0fd5109c4b2
> --- /dev/null
> +++ b/Documentation/arm64/ilp32.txt
> @@ -0,0 +1,45 @@
> +ILP32 AARCH64 SYSCALL ABI
> +=
> +
> +This document describes the ILP32 syscall ABI and where it differs
> +from the generic compat linux syscall interface.

I was hoping to learn what ILP32 is / what is it good for, but no,
this does not tell me... it would be good to do a short explanation
here, and maybe reference it from cover letter of the series...
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH] [v2] docs: clarify security-bugs disclosure policy

[Pavel Machek]

Hi!

On Fri 2018-03-09 13:15:31, Linus Torvalds wrote:
> On Fri, Mar 9, 2018 at 12:45 PM, Alan Cox  wrote:
> >
> > If you want to be taken seriously then I think minimum you also need to
> > - Give a GPG key for messages to the list
> 
> Oh, I don't want to be taken seriously by people who use gpg
> encrypted email.

Heh. I see that gpg has some usability problems, but we do encrypt our
http connections, and email is at least as sensitive.

> > - State what security is in place (encryption etc) to protect the list
> >   itself
> 
> That could be stated, but it's worth noting the other rules.
> 
> If you have some long corrupt vendor disclosure period and are worried
> about any good guys finding out (the bad guys probably already have
> it), we're not the list for you anyway.
> 
> Keep your "we'll keep security problems under wraps so that they can
> be exploited for a long time" emails to yourself, or send them to
> /dev/null.

Umm, they will not sent it to /dev/null, as that is not encrypted :-).

I guess I can act as this kind of /dev/null. It might be useful to
note the issues, and for the serious ones notify you few days before
the "long" embargo is going to expire...

Best regards,

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH V2 5/7] thermal/drivers/cpu_cooling: Add idle cooling device documentation

[Pavel Machek]

Hi!

> >> +Under certain circumstances, the SoC reaches a temperature exceeding
> >> +the allocated power budget or the maximum temperature limit. The
> > 
> > I don't understand. Power budget is in W, temperature is in
> > kelvin. Temperature can't exceed power budget AFAICT.
> 
> Yes, it is badly worded. Is the following better ?
> 
> "
> Under certain circumstances a SoC can reach the maximum temperature
> limit or is unable to stabilize the temperature around a temperature
> control.
> 
> When the SoC has to stabilize the temperature, the kernel can act on a
> cooling device to mitigate the dissipated power.
> 
> When the maximum temperature is reached and to prevent a catastrophic
> situation a radical decision must be taken to reduce the temperature
> under the critical threshold, that impacts the performance.
> 
> "

Actually... if hardware is expected to protect itself, I'd tone it
down. No need to be all catastrophic and critical... But yes, better.

> > Critical here, critical there. I have trouble following
> > it. Theoretically hardware should protect itself, because you don't
> > want kernel bug to damage your CPU?
> 
> There are several levels of protection. The first level is mitigating
> the temperature from the kernel, then in the temperature sensor a reset
> line will trigger the reboot of the CPUs. Usually it is a register where
> you write the maximum temperature, from the driver itself. I never tried
> to write 1000°C in this register and see if I can burn the board.
> 
> I know some boards have another level of thermal protection in the
> hardware itself and some other don't.
> 
> In any case, from a kernel point of view, it is a critical situation as
> we are about to hard reboot the system and in this case it is preferable
> to drop drastically the performance but give the opportunity to the
> system to run in a degraded mode.

Agreed you want to keep going. In ACPI world, we shutdown when
critical trip point is reached, so this is somehow confusing.

> >> +Solutions:
> >> +--
> >> +
> >> +If we can remove the static and the dynamic leakage for a specific
> >> +duration in a controlled period, the SoC temperature will
> >> +decrease. Acting at the idle state duration or the idle cycle
> > 
> > "should" decrease? If you are in bad environment..
> 
> No, it will decrease in any case because of the static leakage drop. The
> bad environment will impact the speed of this decrease.

I meant... if ambient temperature is 105C, there's not much you can do
to cool system down :-).

> >> +Idle Injection:
> >> +---
> >> +
> >> +The base concept of the idle injection is to force the CPU to go to an
> >> +idle state for a specified time each control cycle, it provides
> >> +another way to control CPU power and heat in addition to
> >> +cpufreq. Ideally, if all CPUs of a cluster inject idle synchronously,
> >> +this cluster can get into the deepest idle state and achieve minimum
> >> +power consumption, but that will also increase system response latency
> >> +if we inject less than cpuidle latency.
> > 
> > I don't understand last sentence.
> 
> Is it better ?
> 
> "Ideally, if all CPUs, belonging to the same cluster, inject their idle
> cycle synchronously, the cluster can reach its power down state with a
> minimum power consumption and static leakage drop. However, these idle
> cycles injection will add extra latencies as the CPUs will have to
> wakeup from a deep sleep state."

Extra comma "CPUs , belonging". But yes, better.

> Thanks!

You are welcome. Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v2 2/8] [PATCH 2/8] Documentations: dt-bindings: Add a document of PECI adapter driver for Aspeed AST24xx/25xx SoCs

[Pavel Machek]

Hi!

> >Are these SoCs x86-based?
> 
> Yes, these are ARM SoCs. Please see Andrew's answer as well.

Understood, thanks.

> >>+   Read sampling point selection. The whole period of a bit time will be
> >>+   divided into 16 time frames. This value will determine which time frame
> >>+   this controller will sample PECI signal for data read back. Usually in
> >>+   the middle of a bit time is the best.
> >
> >English? "This value will determine when this controller"?
> >
> 
> Could I change it like below?:
> 
> "This value will determine in which time frame this controller samples PECI
> signal for data read back"

I guess... I'm not native speaker, I guess this could be improved some
more.

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH V2 5/7] thermal/drivers/cpu_cooling: Add idle cooling device documentation

[Pavel Machek]

Hi!

> --- /dev/null
> +++ b/Documentation/thermal/cpu-idle-cooling.txt
> @@ -0,0 +1,165 @@
> +
> +Situation:
> +--
> +

Can we have some real header here? Also if this is .rst, maybe it
should be marked so?

> +Under certain circumstances, the SoC reaches a temperature exceeding
> +the allocated power budget or the maximum temperature limit. The

I don't understand. Power budget is in W, temperature is in
kelvin. Temperature can't exceed power budget AFAICT.

> +former must be mitigated to stabilize the SoC temperature around the
> +temperature control using the defined cooling devices, the latter

later?

> +catastrophic situation where a radical decision must be taken to
> +reduce the temperature under the critical threshold, that can impact
> +the performances.

performance.

> +Another situation is when the silicon reaches a certain temperature
> +which continues to increase even if the dynamic leakage is reduced to
> +its minimum by clock gating the component. The runaway phenomena will
> +continue with the static leakage and only powering down the component,
> +thus dropping the dynamic and static leakage will allow the component
> +to cool down. This situation is critical.

Critical here, critical there. I have trouble following
it. Theoretically hardware should protect itself, because you don't
want kernel bug to damage your CPU?

> +Last but not least, the system can ask for a specific power budget but
> +because of the OPP density, we can only choose an OPP with a power
> +budget lower than the requested one and underuse the CPU, thus losing
> +performances. In other words, one OPP under uses the CPU with a

performance.

> +lesser than the power budget and the next OPP exceed the power budget,
> +an intermediate OPP could have been used if it were present.

was.

> +Solutions:
> +--
> +
> +If we can remove the static and the dynamic leakage for a specific
> +duration in a controlled period, the SoC temperature will
> +decrease. Acting at the idle state duration or the idle cycle

"should" decrease? If you are in bad environment..

> +The Operating Performance Point (OPP) density has a great influence on
> +the control precision of cpufreq, however different vendors have a
> +plethora of OPP density, and some have large power gap between OPPs,
> +that will result in loss of performance during thermal control and
> +loss of power in other scenes.

scene seems to be wrong word here.

> +At a specific OPP, we can assume injecting idle cycle on all CPUs,

Extra comma?

> +Idle Injection:
> +---
> +
> +The base concept of the idle injection is to force the CPU to go to an
> +idle state for a specified time each control cycle, it provides
> +another way to control CPU power and heat in addition to
> +cpufreq. Ideally, if all CPUs of a cluster inject idle synchronously,
> +this cluster can get into the deepest idle state and achieve minimum
> +power consumption, but that will also increase system response latency
> +if we inject less than cpuidle latency.

I don't understand last sentence.

> +The mitigation begins with a maximum period value which decrease

decreases?
  
> +more cooling effect is requested. When the period duration is equal
> to
> +the idle duration, then we are in a situation the platform can’t
> +dissipate the heat enough and the mitigation fails. In this case

fast enough?

> +situation is considered critical and there is nothing to do. The idle

Nothing to do? Maybe power the system down?

> +The idle injection duration value must comply with the constraints:
> +
> +- It is lesser or equal to the latency we tolerate when the mitigation

less ... than the latency

> +Minimum period
> +--
> +
> +The idle injection duration being fixed, it is obvious the minimum
> +period can’t be lesser than that, otherwise we will be scheduling the

less.

> +Practically, if the running power is lesses than the targeted power,

less.

> +However, in this demonstration we ignore three aspects:
> +
> + * The static leakage is not defined here, we can introduce it in the
> +   equation but assuming it will be zero most of the time as it is

, but?

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v2 2/8] [PATCH 2/8] Documentations: dt-bindings: Add a document of PECI adapter driver for Aspeed AST24xx/25xx SoCs

[Pavel Machek]

On Tue 2018-03-06 13:54:16, Andrew Lunn wrote:
> On Tue, Mar 06, 2018 at 01:40:02PM +0100, Pavel Machek wrote:
> > Hi!
> > 
> > > Signed-off-by: Jae Hyun Yoo <jae.hyun@linux.intel.com>
> > > ---
> > >  .../devicetree/bindings/peci/peci-aspeed.txt   | 73 
> > > ++
> > >  1 file changed, 73 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/peci/peci-aspeed.txt
> > > 
> > > diff --git a/Documentation/devicetree/bindings/peci/peci-aspeed.txt 
> > > b/Documentation/devicetree/bindings/peci/peci-aspeed.txt
> > > new file mode 100644
> > > index ..8a86f346d550
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/peci/peci-aspeed.txt
> > > @@ -0,0 +1,73 @@
> > > +Device tree configuration for PECI buses on the AST24XX and AST25XX SoCs.
> > 
> > Are these SoCs x86-based?
> 
> ARM, as far as i can tell. If i get the architecture correct, these
> are BMC, Board Management Controllers, looking after the main x86 CPU,
> stopping it overheating, controlling the power supplies, remote
> management, etc.

Ok, so with x86 machine, I get arm-based one for free. I get it. Is
user able to run his own kernel on the arm system, or is it locked
down, TiVo style?

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v2 2/8] [PATCH 2/8] Documentations: dt-bindings: Add a document of PECI adapter driver for Aspeed AST24xx/25xx SoCs

[Pavel Machek]

Hi!

> Signed-off-by: Jae Hyun Yoo 
> ---
>  .../devicetree/bindings/peci/peci-aspeed.txt   | 73 
> ++
>  1 file changed, 73 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/peci/peci-aspeed.txt
> 
> diff --git a/Documentation/devicetree/bindings/peci/peci-aspeed.txt 
> b/Documentation/devicetree/bindings/peci/peci-aspeed.txt
> new file mode 100644
> index ..8a86f346d550
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/peci/peci-aspeed.txt
> @@ -0,0 +1,73 @@
> +Device tree configuration for PECI buses on the AST24XX and AST25XX SoCs.

Are these SoCs x86-based?

> +Required properties:
> +- compatible
> + "aspeed,ast2400-peci" or "aspeed,ast2500-peci"
> + - aspeed,ast2400-peci: Aspeed AST2400 family PECI controller
> + - aspeed,ast2500-peci: Aspeed AST2500 family PECI controller
> +
> +- reg
> + Should contain PECI registers location and length.

Other dts documents put it on one line, reg: Should contain ...

> +- clock_frequency
> + Should contain the operation frequency of PECI hardware module.
> + 187500 ~ 2400

specify this is Hz?

> +- rd-sampling-point
> + Read sampling point selection. The whole period of a bit time will be
> + divided into 16 time frames. This value will determine which time frame
> + this controller will sample PECI signal for data read back. Usually in
> + the middle of a bit time is the best.

English? "This value will determine when this controller"?

> + 0 ~ 15 (default: 8)
> +
> +- cmd_timeout_ms
> + Command timeout in units of ms.
> + 1 ~ 6 (default: 1000)
> +
> +Example:
> + peci: peci@1e78b000 {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x1e78b000 0x60>;
> +
> + peci0: peci-bus@0 {
> + compatible = "aspeed,ast2500-peci";
> + reg = <0x0 0x60>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interrupts = <15>;
> + clocks = <_clkin>;
> + clock-frequency = <2400>;
> + msg-timing-nego = <1>;
> + addr-timing-nego = <1>;
> + rd-sampling-point = <8>;
> + cmd-timeout-ms = <1000>;
> + };
> + };
> \ No newline at end of file

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v6 00/11] Intel SGX Driver

[Pavel Machek]

On Tue 2018-01-09 16:27:30, Jarkko Sakkinen wrote:
> On Thu, Jan 04, 2018 at 03:17:24PM +0100, Cedric Blancher wrote:
> > So how does this protect against the MELTDOWN attack (CVE-2017-5754)
> > and the MELTATOMBOMBA4 worm which uses this exploit?
> > 
> > Ced
> 
> Everything going out of L1 gets encrypted. This is done to defend
> against peripheral like adversaries and should work also against
> meltdown.

Yeah, but useless against spectre and ability to introduce bit flips
means this is generally useless...

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v6 00/11] Intel SGX Driver

[Pavel Machek]

Hi!

> Good evening Pavel et.al., I hope the New Year has started well for
> everyone.

:-). Stuff proceeds as usual. Too bad it is raining outside, instead
of snowing.

> > > > Would you list guarantees provided by SGX?
> > >
> > > Obviously, confidentiality and integrity.  SGX was designed to address
> > > an Iago threat model, a very difficult challenge to address in
> > > reality.
> 
> > Do you have link on "Iago threat model"?
> 
> https://cseweb.ucsd.edu/~hovav/dist/iago.pdf
> 
> > > I don't have the citation immediately available, but a bit-flip attack
> > > has also been described on enclaves.  Due to the nature of the
> > > architecture, they tend to crash the enclave so they are more in the
> > > category of a denial-of-service attack, rather then a functional
> > > confidentiality or integrity compromise.
> 
> > So ... even with SGX, host can generate bitflips in the enclave,
> > right?
> 
> Correct.

...

I'd say that you can't generate bitflips because if you do hardware
will kill the enclave. This seems to be significant difference from
AMD "secure" memory encryption...

> > People usually assume that bitflip will lead "only" to
> > denial-of-service, but rowhammer work shows that even "random" bit
> > flips easily lead to priviledge escalation on javascript virtual
> > machines, and in similar way you can get root if you have user and
> > bit flips happen.
> >
> > So... I believe we should assume compromise is possible, not just
> > denial-of-service.
> 
> Prudence always dictates that one assumes the worst.  In this case
> however, the bitflip attacks against SGX enclaves are very definitely
> in the denial-of-service category.  The attack is designed to trigger
> a hardware self-protection feature on the processor.
> 
> Each page of memory which is initialized into an enclave has a
> metadata block associated with it which contains the integrity state
> of that page of memory.  The MM{E,U} hardware on an SGX capable
> platform checks this integrity data on each page fetch request arising
> from addresses/pages inside of an enclave.
> 
> Forcing a bitflip in enclave memory causes the next page fetch
> containing the bitflipped location to fail its integrity check.  Since
> this technically shouldn't be possible, this situation was classified
> as a hardware failure which is handled by the processor locking its
> execution state, thus taking the machine down.

So you can't really do bitflips on the SGX protected memory, because
MM{E,U} hardware will catch that and kill machine if you try?

So SGX protected memory is not swappable?

> It would seem to be a misfeature for the self-protection mechanism to
> not generate some type of trappable fault rather then generating a
> processor lockup but hindsight is always 20/20.  Philosophically this
> is a good example of security risk managment.  Locking a machine is
> obviously problematic in a cloud service environment, but it has to be
> taken in the perspective of whether or not it would be preferable to
> have a successful privilege escalation attack which could result in
> exfiltration of sensitive data.

Ok, right, it should fault. They can fix it in new version?

> > Well, yes :-). And I believe someone is going to have fun with SGX
> > ;-).
> 
> Arguably not as much fun as what appears to be pending, given what
> appears to be the difficulty of some Intel processors to deal with
> page faults induced by speculative memory references... :-)

Do you have more info on that? Will they actually leak information, or
is it just good for rowhammering the kernel memory?


Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v6 00/11] Intel SGX Driver

[Pavel Machek]

Hi!

> > Would you list guarantees provided by SGX?
> 
> Obviously, confidentiality and integrity.  SGX was designed to address
> an Iago threat model, a very difficult challenge to address in
> reality.

Do you have link on "Iago threat model"?

> I don't have the citation immediately available, but a bit-flip attack
> has also been described on enclaves.  Due to the nature of the
> architecture, they tend to crash the enclave so they are more in the
> category of a denial-of-service attack, rather then a functional
> confidentiality or integrity compromise.

So ... even with SGX, host can generate bitflips in the enclave,
right?

People usually assume that bitflip will lead "only" to
denial-of-service, but rowhammer work shows that even "random" bit
flips easily lead to priviledge escalation on javascript virtual
machines, and in similar way you can get root if you have user and bit
flips happen.

So... I believe we should assume compromise is possible, not just
denial-of-service.

> Unfortunately, in the security field it is way more fun, and seemingly
> advantageous from a reputational perspective, to break things then to
> build solutions :-)(

Well, yes :-). And I believe someone is going to have fun with SGX
;-).
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v6 00/11] Intel SGX Driver

[Pavel Machek]

On Sat 2017-11-25 21:29:17, Jarkko Sakkinen wrote:
> Intel(R) SGX is a set of CPU instructions that can be used by applications to
> set aside private regions of code and data. The code outside the enclave is
> disallowed to access the memory inside the enclave by the CPU access control.
> In a way you can think that SGX provides inverted sandbox. It protects the
> application from a malicious host.

Would you list guarantees provided by SGX?

For example, host can still observe timing of cachelines being
accessed by "protected" app, right? Can it also introduce bit flips?

Pavel
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] thinkpad_acpi: Support the battery wear control

[Pavel Machek]

On Sat 2017-12-09 11:29:51, Ognjen Galić wrote:
> On 09/12/2017, Pavel Machek <pa...@ucw.cz> wrote:
> > In newer series (I can't find it at the moment, sorry)
> 
> The new series is a 3-patch patchset that obsoletes this
> patch. It is in the testing stage and will be pushed to
> the mailing lists and maintainers in a few days.
> 
> > Maybe we should have separate status "not charging due to wear
> > control"?
> 
> No, because the ACPI battery driver is a extension to the generic
> power supply driver, that does not understand the battery wear control.
> Also, Rafael specifically noted NOT to include any thinkpad_acpi-specific
> behavior to the generic drivers.

Yeah, what I'm saying is that maybe we need to extend generic power
supply driver.

On small devices, we usually have enough control over hardware to be
able to implement "wear control" in kernel. Nokia N900 is an
example. "Wear control" is certainly not thinkpad-specific concept.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v2] thinkpad_acpi: Support the battery wear control

[Pavel Machek]

Hi!

In newer series (I can't find it at the moment, sorry) you return
"NOT_CHARGING" status when not charging because of wear control.

Maybe we should have separate status "not charging due to wear
control"?

Thanks,

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH 04/24] media: v4l2-mediabus: convert flags to enums and document them

[Pavel Machek]

On Mon 2017-10-09 07:19:10, Mauro Carvalho Chehab wrote:
> There is a mess with media bus flags: there are two sets of
> flags, one used by parallel and ITU-R BT.656 outputs,
> and another one for CSI2.
> 
> Depending on the type, the same bit has different meanings.
> 

> @@ -86,11 +125,22 @@ enum v4l2_mbus_type {
>  /**
>   * struct v4l2_mbus_config - media bus configuration
>   * @type:in: interface type
> - * @flags:   in / out: configuration flags, depending on @type
> + * @pb_flags:in / out: configuration flags, if @type is
> + *   %V4L2_MBUS_PARALLEL or %V4L2_MBUS_BT656.
> + * @csi2_flags:  in / out: configuration flags, if @type is
> + *   %V4L2_MBUS_CSI2.
> + * @flag:access flags, no matter the @type.
> + *   Used just to avoid needing to rewrite the logic inside
> + *   soc_camera and pxa_camera drivers. Don't use on newer
> + *   drivers!
>   */
>  struct v4l2_mbus_config {
>   enum v4l2_mbus_type type;
> - unsigned int flags;
> + union {
> + enum v4l2_mbus_parallel_and_bt656_flags pb_flags;
> + enum v4l2_mbus_csi2_flags   csi2_flags;
> + unsigned intflag;
> + };
>  };
>  
>  static inline void v4l2_fill_pix_format(struct v4l2_pix_format
>  *pix_fmt,

The flags->flag conversion is quite subtle, and "flag" is confusing
because there is more than one inside. What about something like
__legacy_flags?

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

[Pavel Machek]

On Wed 2017-09-20 22:08:42, Jacek Anaszewski wrote:
> On 09/20/2017 01:29 PM, Pavel Machek wrote:
> >>>>> I'd leave the decision to the user. We could add a note to the
> >>>>> Documentation/leds/ledtrig-transient.txt that force feedback interface
> >>>>> should be preferable choice for driving vibrate devices.
> >>>>> However only if following conditions are met:
> >>>>
> >>>> What I meant is that it is my decision, as a LED subsystem maintainer,
> >>>> to accept the addition of a note about some other subsystem offering
> >>>> an equivalent or even better substitute of the feature being available
> >>>> in the subsystem I am responsible for. And I will accept such a patch
> >>>> only if mentioned conditions are met.
> >>>
> >>> Having the wording in documentation does not in any way stops Android
> >>> folks from continuing [ab]using the transient trigger. But this is
> >>> their choice. The purpose of documentation is to document the best
> >>> practices, not all possible crazy solutions one can come up with.
> >>
> >> Yes. but if the information has been in place for years, we can't
> >> just remove it without giving an instruction on how to use the
> >> substitute.
> > 
> > I gave you information how to use the substitute.
> 
> That information was quite vague. I'd like to see a sample application
> in tools/input.

So please write it.

> > I already suggested patch to documentation. If you do the same, maybe
> > we can agree on documentation update.
> 
> Your patch was just removing few lines of documentation. I'd expect more
> empathic approach to the current users, i.e.:
> 
> - pointer to the sample application in tools/input showing how to
>   setup gpio driven vibrate device with use of ff interface with
>   1kHz vibration frequency.

Yes, my patch is removing dangerously misleading documentation about
LED subsystem.

Please apply it.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH 3/3 v12] printk: Add monotonic, boottime, and realtime timestamps

[Pavel Machek]

Hi!

> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index b19c491cbc4e..e21b0c002d0f 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -8,12 +8,58 @@ config PRINTK_TIME
> messages to be added to the output of the syslog() system
> call and at the console.
>  
> +choice
> + prompt "printk default clock timestamp" if PRINTK_TIME
> + default PRINTK_TIME_LOCAL if PRINTK_TIME
> + help
> +   This option is selected by setting one of
> +   PRINTK_TIME_[DISABLE|LOCAL|BOOT|MONO|REAL] and causes time stamps of
> +   the printk() messages to be added to the output of the syslog()
> +   system call and at the console.
> +
> The timestamp is always recorded internally, and exported
> to /dev/kmsg. This flag just specifies if the timestamp should
> be included, not that the timestamp is recorded.
>  
> The behavior is also controlled by the kernel command line
> -   parameter printk.time=1. See 
> Documentation/admin-guide/kernel-parameters.rst
> +   parameter printk.time. See
> +   Documentation/admin-guide/kernel-parameters.rst
> +
> +config PRINTK_TIME_LOCAL
> + bool "Local Clock"
> + help
> +   Selecting this option causes the time stamps of printk() to be
> +   stamped with the unadjusted hardware clock.
> +
> +config PRINTK_TIME_BOOT
> + bool "Boot Time Clock"
> + help
> +   Selecting this option causes the time stamps of printk() to be
> +   stamped with the adjusted boottime clock.
> +
> +config PRINTK_TIME_MONO
> + bool "Monotonic Clock"
> + help
> +   Selecting this option causes the time stamps of printk() to be
> +   stamped with the adjusted monotonic clock.
> +
> +config PRINTK_TIME_REAL
> + bool "Real Time Clock"
> + help
> +   Selecting this option causes the time stamps of printk() to be
> +   stamped with the adjusted realtime clock (UTC).
> +endchoice
> +
> +config PRINTK_TIME_TYPE
> + int
> + depends on PRINTK
> + range 0 4
> + default 0 if !PRINTK_TIME
> + default 1 if PRINTK_TIME_LOCAL
> + default 2 if PRINTK_TIME_BOOT
> + default 3 if PRINTK_TIME_MONO
> + default 4 if PRINTK_TIME_REAL
> +
>  
>  config CONSOLE_LOGLEVEL_DEFAULT
>   int "Default console loglevel (1-15)"

Come on, you don't need to ask user just to set default value to be
overriden by command line. This is not nearly important enough.

Drop it. You can still use CONFIG_CMDLINE="...".

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

[Pavel Machek]

> >>> I'd leave the decision to the user. We could add a note to the
> >>> Documentation/leds/ledtrig-transient.txt that force feedback interface
> >>> should be preferable choice for driving vibrate devices.
> >>> However only if following conditions are met:
> >>
> >> What I meant is that it is my decision, as a LED subsystem maintainer,
> >> to accept the addition of a note about some other subsystem offering
> >> an equivalent or even better substitute of the feature being available
> >> in the subsystem I am responsible for. And I will accept such a patch
> >> only if mentioned conditions are met.
> > 
> > Having the wording in documentation does not in any way stops Android
> > folks from continuing [ab]using the transient trigger. But this is
> > their choice. The purpose of documentation is to document the best
> > practices, not all possible crazy solutions one can come up with.
> 
> Yes. but if the information has been in place for years, we can't
> just remove it without giving an instruction on how to use the
> substitute.

I gave you information how to use the substitute.

I already suggested patch to documentation. If you do the same, maybe
we can agree on documentation update.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

[Pavel Machek]

Hi!

> >> However only if following conditions are met:
> >> - force feedback driver supports gpio driven devices
> >> - there is sample application in tools/input showing how to
> >>   setup gpio driven vibrate device with use of ff interface
> >> - it will be possible to setup vibrate interval with 1ms accuracy,
> >>   similarly to what the discussed patch allows to do
> > 
> > I agree these would be nice. Interested parties are welcome to help
> > there. But I don't think this should have any impact on LED
> > susbystem. Force feedback just does not belong to LED subsystem.
> 
> You cut off important piece of my text from the beginning of this
> paragraph. It was:
> 
> > I'd leave the decision to the user. We could add a note to the
> > Documentation/leds/ledtrig-transient.txt that force feedback interface
> > should be preferable choice for driving vibrate devices.
> > However only if following conditions are met:

And that's very bad idea.

As a user of these interfaces, I am telling you: I want _single_
kernel interface to control vibration. Not different interfaces
depending on which phone I'm running at.

> What I meant is that it is my decision, as a LED subsystem maintainer,
> to accept the addition of a note about some other subsystem offering
> an equivalent or even better substitute of the feature being available
> in the subsystem I am responsible for. And I will accept such a patch
> only if mentioned conditions are met.

If you want to improve input, please go ahead.

If you want to encourage haptic feedback to use LED subsystem, that is
not welcome.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

[Pavel Machek]

On Mon 2017-09-18 22:43:40, Jacek Anaszewski wrote:
> Hi,
> 
> On 09/17/2017 07:50 PM, Pavel Machek wrote:
> > Hi!
> > 
> >>>> Do you think such an improvement could be harmful in some way,
> >>>> even if it was made optional?
> >>>
> >>> Of course, we can make LED timing accurate down to microseconds. It will
> >>> mean increased overhead -- for "improvement" human can not perceive.
> >>>
> >>> If someone has problems with LED delays not being accurate enough... we
> >>> may want to fix it. But that is not the case here, is it?
> >>
> >> AFAIR David was mentioning that the hr_timer support is perceivable
> > 
> > He said that hr_timer support is perceivable _when he is driving
> > vibration motor_. Which he should not do in the first place.
> > 
> > Yes, if the difference is perceivable with LED in non-crazy
> > configuration (*), we can take the patch. Is it? Do we have someone
> > not from Google observing it?
> > 
> > (*) emulating PWM using blink trigger counts as "crazy" :-)
> 
> How about adding CONFIG_LED_TRIGGERS_HR_TIMER_SUPPORT, guarding the
> hr timer support in triggers (timer trigger could also benefit from it)
> with it, and adding "(EXPERIMENTAL)" tag to the config description?

Why would we want to add code in the LED subsystem that is useless for
LEDs?
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

[Pavel Machek]

Hi!

> >> Do you think such an improvement could be harmful in some way,
> >> even if it was made optional?
> > 
> > Of course, we can make LED timing accurate down to microseconds. It will
> > mean increased overhead -- for "improvement" human can not perceive.
> > 
> > If someone has problems with LED delays not being accurate enough... we
> > may want to fix it. But that is not the case here, is it?
> 
> AFAIR David was mentioning that the hr_timer support is perceivable

He said that hr_timer support is perceivable _when he is driving
vibration motor_. Which he should not do in the first place.

Yes, if the difference is perceivable with LED in non-crazy
configuration (*), we can take the patch. Is it? Do we have someone
not from Google observing it?

Pavel
(*) emulating PWM using blink trigger counts as "crazy" :-)


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[PATCH] Documentation: link in networking docs

[Pavel Machek]

Fix link in filter.txt.

Acked-by: Pavel Machek <pa...@ucw.cz>

diff --git a/Documentation/networking/filter.txt 
b/Documentation/networking/filter.txt
index e5e33ba..789b74d 100644
--- a/Documentation/networking/filter.txt
+++ b/Documentation/networking/filter.txt
@@ -45,7 +45,7 @@ in many more places. There's xt_bpf for netfilter, cls_bpf in 
the kernel
 qdisc layer, SECCOMP-BPF (SECure COMPuting [1]), and lots of other places
 such as team driver, PTP code, etc where BPF is being used.
 
- [1] Documentation/prctl/seccomp_filter.txt
+ [1] Documentation/userspace-api/seccomp_filter.rst
 
 Original BPF paper:
 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

[Pavel Machek]

Hi!

> >> If we want to have discussion "how to make vibrations in input
> >> easier to use", well that's fair. But I don't think it is particulary hard.
> >>
> > 
> > I would like to know more about why you find the FF interface hard,
> 
> led-transient trigger can be activated using only following bash
> commands:
> 
> # echo 1 > state
> # echo 1000 > duration
> # while [ 1 ]; do echo 1 > activate; sleep 3; done
> 
> Could you share sample sequence of commands to use ff driver?

Well, LED transient trigger can be activated like that. But that will
not work on any hardware currently supported by the mainline kernel.

Equivalent command with forcefeedback is:

(echo 5; sleep 1; echo -1) | sudo fftest /dev/input/event2

You would not want to use either in production.

> >> But having half devices use one interface and half use different one
> >> is just bad...
> > 
> > Completely agree here. I just merged PWM vibra driver from Sebastian
> > Reichel, we already had regulator-haptic driver, do we need gpio-based
> > one? Or make regulator-based one working with fixed regulators?
> 
> Just to clarify: the background of this discussion is the question
> whether we should remove the following lines from
> Documentation/leds/ledtrig-transient.txt:
> 
> -As a specific example of this use-case, let's look at vibrate feature on
> -phones. Vibrate function on phones is implemented using PWM pins on SoC or
> -PMIC. There is a need to activate one shot timer to control the vibrate
> -feature, to prevent user space crashes leaving the phone in vibrate mode
> -permanently causing the battery to drain.
> whether we should remove the following use case example from
> 
> In effect Pavel has objections to increasing ledtrig-transient
> interval accuracy by adding hr_timer support to it, because vibrate
> devices, as one of the use cases, can benefit from it.
> 
> So there are two issues:
> 1. Addition of hr_timer support to LED trigger.
> 2. Removal of vibrate devices use case from ledtrig-transient doc.
> 
> I am in favour of 1. and against 2. since we're not gaining anything
> by hiding information about some kernel functionality when it will
> still be there. It also doesn't define the location of any vibrate
> device drivers, since sheer leds-gpio driver can be used for that
> purpose.

I would like to see reasonable explanation why we want 1. (and
vibrations are not that) and certainly 2. because we don't want people
to use LED subsystem for vibrations.

We already have perfectly good interface for that.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

[Pavel Machek]

Hi!

>  These patch series add the LED_BRIGHTNESS_FAST flag support for
>  ledtrig-transient to use hrtimer so that platforms with high-resolution 
>  timer
>  support can have better accuracy in the trigger duration timing. The 
>  need for
...
> > If we want to say "lets move all vibrations from input to LED
> > subsystem"... I don't think that is good idea, but its a valid
> > discussion. Some good reasons would be needed.
> > 
> > But having half devices use one interface and half use different one
> > is just bad... especially when only reason to do it that way is
> > "David wants to do it that way, android library made a mistake and he
> > now wants it to propagate to whole world".
> 
> This is not the only reason. Adding hr_timer support to
> ledtrig-transient (and similarly to ledtrig-timer) would allow
> to increase the accuracy and stability of delay_on/delay_off
> intervals at low values.
> 
> Do you think such an improvement could be harmful in some way,
> even if it was made optional?

Of course, we can make LED timing accurate down to microseconds. It will
mean increased overhead -- for "improvement" human can not perceive.

If someone has problems with LED delays not being accurate enough... we
may want to fix it. But that is not the case here, is it?
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Documentation: fix ascii art in networking docs

[Pavel Machek]

Fix ascii-art.

Signed-off-by: Pavel Machek <pa...@ucw.cz>

diff --git a/Documentation/networking/switchdev.txt 
b/Documentation/networking/switchdev.txt
index 5e40e1f..6309e90 100644
--- a/Documentation/networking/switchdev.txt
+++ b/Documentation/networking/switchdev.txt
@@ -29,7 +29,7 @@ with SR-IOV or soft switches, such as OVS, are possible.
   sw1p1  +  sw1p3  +  sw1p5  +  eth1
 +|+|+|+
 |||||||
- +--++++-+--++---+  +-+-+
+ +--++++++---+  +-+-+
  | Switch driver |  |mgmt   |
  |(this document)|  |   driver  |
  |   |  |   |

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

[Pavel Machek]

On Thu 2017-09-14 21:31:31, Jacek Anaszewski wrote:
> Hi David and Pavel,
> 
> On 09/13/2017 10:20 PM, Pavel Machek wrote:
> > Hi!
> > 
> >> These patch series add the LED_BRIGHTNESS_FAST flag support for
> >> ledtrig-transient to use hrtimer so that platforms with high-resolution 
> >> timer
> >> support can have better accuracy in the trigger duration timing. The need 
> >> for
> >> this support is driven by the fact that Android has removed the 
> >> timed_ouput [1]
> >> and is now using led-trigger for handling vibrator control which requires 
> >> the
> >> timer to be accurate up to a millisecond. However, this flag support would 
> >> also
> >> allow hrtimer to co-exist with the ktimer without causing warning to the
> >> existing drivers [2].
> > 
> > NAK.
> > 
> > LEDs do not need extra overhead, and vibrator control should not go
> > through LED subsystem.
> > 
> > Input subsystem includes support for vibrations and force
> > feedback. Please use that instead.
> 
> I think that most vital criterion here is the usability of the
> interface. If it can be harnessed for doing the work seemingly
> unrelated to the primary subsystem's purpose, that's fine.
> Moreover, it is extremely easy to use in comparison to the force
> feedback one.

Well, no.

Kernel is supposed to provide hardware abstraction, that means it
should hide differences between different devices.

And we already have devices using input as designed. We don't want to
have situation where "on phones A, D and E, vibrations are handled via
input, while on B, C and F, they are handled via /sys/class/leds".

If we want to have discussion "how to make vibrations in input
easier to use", well that's fair. But I don't think it is particulary hard.

If we want to say "lets move all vibrations from input to LED
subsystem"... I don't think that is good idea, but its a valid
discussion. Some good reasons would be needed.

But having half devices use one interface and half use different one
is just bad... especially when only reason to do it that way is
"David wants to do it that way, android library made a mistake and he
now wants it to propagate to whole world".

Thank you,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

[Pavel Machek]

Hi!

> > > > NAK.
> > > >
> > > > LEDs do not need extra overhead, and vibrator control should not go
> > > > through LED subsystem.
> > > >
> > > > Input subsystem includes support for vibrations and force
> > > > feedback. Please use that instead.
> > >
> > > I thought we are already over this discussion. As of now, the support
> > > of vibrator through ledtrig is documented
> > > (Documentation/leds/ledtrig-transient.txt) and there are users using
> > > it.

Stop misleading people. No _users_ are using Android on mainline
kernel, as there is not a single Android phone supported by mainline
kernel.

> > I also thought we are over with that discussion.
> >
> > Yes, I'm working on fixing the docs.
> >
> > What mainline users are doing that?
> 
> Please refer to patch:
> https://patchwork.kernel.org/patch/8664831/ and
> https://android.googlesource.com/platform%2Fhardware%2Flibhardware/+/61701df363310a5cbd95e3e1638baa9526e42c9b
> 
> I don't think currently there are drivers in the mainline using it
> yet, the reason being most of the Android devices are still on 4.4
> kernel which still uses the legacy timed_output device.

Ok. I'm sorry commit 61701df363310a5cbd95e3e1638baa9526e42c9b pushed
your libhardware into wrong direction, but that is exactly what
happened.

LED subsystem is not suitable for vibrations. We have input subsystem
for that, it is handling vibrations for 10+ years, and for example
Nokia N900 cellphone (which is supported by mainline) uses them.

Please fix libhardware accordingly.

Thank you,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

[Pavel Machek]

On Wed 2017-09-13 14:20:58, David Lin wrote:
> On Wed, Sep 13, 2017 at 1:20 PM, Pavel Machek <pa...@ucw.cz> wrote:
> >
> > Hi!
> >
> > > These patch series add the LED_BRIGHTNESS_FAST flag support for
> > > ledtrig-transient to use hrtimer so that platforms with high-resolution 
> > > timer
> > > support can have better accuracy in the trigger duration timing. The need 
> > > for
> > > this support is driven by the fact that Android has removed the 
> > > timed_ouput [1]
> > > and is now using led-trigger for handling vibrator control which requires 
> > > the
> > > timer to be accurate up to a millisecond. However, this flag support 
> > > would also
> > > allow hrtimer to co-exist with the ktimer without causing warning to the
> > > existing drivers [2].
> >
> > NAK.
> >
> > LEDs do not need extra overhead, and vibrator control should not go
> > through LED subsystem.
> >
> > Input subsystem includes support for vibrations and force
> > feedback. Please use that instead.
> 
> I thought we are already over this discussion. As of now, the support
> of vibrator through ledtrig is documented
> (Documentation/leds/ledtrig-transient.txt) and there are users using
> it.

I also thought we are over with that discussion.

Yes, I'm working on fixing the docs.

What mainline users are doing that?

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

[Pavel Machek]

Hi!

> These patch series add the LED_BRIGHTNESS_FAST flag support for
> ledtrig-transient to use hrtimer so that platforms with high-resolution timer
> support can have better accuracy in the trigger duration timing. The need for
> this support is driven by the fact that Android has removed the timed_ouput 
> [1]
> and is now using led-trigger for handling vibrator control which requires the
> timer to be accurate up to a millisecond. However, this flag support would 
> also
> allow hrtimer to co-exist with the ktimer without causing warning to the
> existing drivers [2].

NAK.

LEDs do not need extra overhead, and vibrator control should not go
through LED subsystem.

Input subsystem includes support for vibrations and force
feedback. Please use that instead.

Pavel

> David Lin (3):
>   leds: Replace flags bit shift with BIT() macros
>   leds: Add the LED_BRIGHTNESS_FAST flag
>   led: ledtrig-transient: add support for hrtimer
> 
>  Documentation/leds/leds-class.txt|  5 +++
>  drivers/leds/trigger/ledtrig-transient.c | 59 
> +---
>  include/linux/leds.h | 19 +-
>  3 files changed, 69 insertions(+), 14 deletions(-)
> 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data Integrity)

[Pavel Machek]

On Tue 2017-09-05 14:44:56, David Miller wrote:
> From: Pavel Machek <pa...@ucw.cz>
> Date: Mon, 4 Sep 2017 18:25:30 +0200
> 
> > Will gcc be able to compile code that uses these automatically? That
> > does not sound easy to me. Can libc automatically use this in malloc()
> > to prevent accessing freed data when buffers are overrun?
> > 
> > Is this for benefit of JITs?
> 
> Anything that can control mappings and the virtual address used to
> access memory can use ADI.
> 
> malloc() is of course one such case.  It can map memory with ADI
> enabled, and return buffer addresses to malloc() callers with the
> proper virtual address bits set to satisfy the ADI key checks.
> 
> And by induction anything using malloc() for it's memory allocation
> gets ADI protection as well.

I see; that's actually quite a nice trick.

I guess it does not protect against stack-based overflows, but should
help against heap-based overflows, so it improves security a bit, too.

Nice, thanks for explanation.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH] Documentation: small fixes for LEDs, hide notes about vibration

[Pavel Machek]

Hi!

> >> > -As a specific example of this use-case, let's look at vibrate feature on
> >> > -phones. Vibrate function on phones is implemented using PWM pins on SoC 
> >> > or
> >> > -PMIC. There is a need to activate one shot timer to control the vibrate
> >> > -feature, to prevent user space crashes leaving the phone in vibrate mode
> >> > -permanently causing the battery to drain.
> >> 
> >> I'm not sure if it is a good idea to remove this description. Users will
> >> still be able to use transient trigger this way. It has been around for
> >> five years already and there are users which employ it in this
> >> particular way [0].
> >
> > I am. Yes, people were doing that, but no, vibration motor is not a
> > LED. PWM behaviour is different, for example, motor is likely to stop
> > at low PWM values. We do not want people to do that.
> >
> >> Apart from that it's the only documented kernel API for vibrate devices
> >> AFAICT.
> >
> > Input subsystem has force-feedback protocol, which is very often just
> > vibrations. Documentation/input/ff.rst . Nokia N900 phone actually
> > uses that API.
> 
> N900 as shipped by Nokia used an ad hoc sysfs interface. Because that
> sucked, I advocated using the force feedback API for N950 and
> N9. Because what is vibration but force feedback? It's a much more
> versatile API for vibration than a simple trigger. You get to upload
> effects and have the kernel play them for you, also stopping them in a
> timely manner regardless of the userspace dying and whatnot. I didn't
> double check now, but IIRC you could also link the input to force
> feedback, e.g. for touch vibrations.

Ok, N900 support in mainline actually uses force feedback, as in N9,
N950. It is the right interface.

AFAICT, no mainline ARM board uses LEDs for vibrations. And I hope to
keep it that way :-).

(OpenMoko gta01 did that, IIRC. But that is not mainline, good).
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH] Documentation: small fixes for LEDs, hide notes about vibration

[Pavel Machek]

Hi!

> > -As a specific example of this use-case, let's look at vibrate feature on
> > -phones. Vibrate function on phones is implemented using PWM pins on SoC or
> > -PMIC. There is a need to activate one shot timer to control the vibrate
> > -feature, to prevent user space crashes leaving the phone in vibrate mode
> > -permanently causing the battery to drain.
> 
> I'm not sure if it is a good idea to remove this description. Users will
> still be able to use transient trigger this way. It has been around for
> five years already and there are users which employ it in this
> particular way [0].

I am. Yes, people were doing that, but no, vibration motor is not a
LED. PWM behaviour is different, for example, motor is likely to stop
at low PWM values. We do not want people to do that.

> Apart from that it's the only documented kernel API for vibrate devices
> AFAICT.

Input subsystem has force-feedback protocol, which is very often just
vibrations. Documentation/input/ff.rst . Nokia N900 phone actually
uses that API.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH] Documentation: fix little inconsistencies

[Pavel Machek]

On Tue 2017-08-29 13:09:45, Jonathan Corbet wrote:
> On Tue, 29 Aug 2017 09:50:57 -0700
> "Darrick J. Wong"  wrote:
> 
> > > Anything wrong here? It is fixing extra '+' in the ascii art...  
> > 
> > There's nothing incorrect here, I merely thought it odd to send a fix
> > for networking documentation to the ext4 list, but not netdev?
> 
> In fact, davem likes to handle networking documentation patches himself,
> so resending this one to netdev would be a good idea.

Its a typo in documentation, do we really need to waste any more time
with it? Dave, can you just ack it?

> > index 5e40e1f..6309e90 100644
> > --- a/Documentation/networking/switchdev.txt
> > +++ b/Documentation/networking/switchdev.txt
> > @@ -29,7 +29,7 @@ with SR-IOV or soft switches, such as OVS, are
> > possible.
> >    sw1p1  +  sw1p3  +  sw1p5  +  eth1
> >  +|+|+|+
> >  |||||||
> > - +--++++-+--++---+  +-+-+
> > + +--++++++---+  +-+-+

Besides, if documentation fixes should go to Davem/netdev,
getmaintainer.pl should say so:

pavel@duo:/data/l/linux-n900$ scripts/get_maintainer.pl -f
Documentation/networking
Jonathan Corbet  (maintainer:DOCUMENTATION)
"David S. Miller"  (commit_signer:52/87=60%)
David Howells 
(commit_signer:7/87=8%,authored:8/87=9%)
Florian Fainelli  (commit_signer:6/87=7%)
Mauro Carvalho Chehab 
(commit_signer:6/87=7%,authored:5/87=6%)
Yuchung Cheng  (commit_signer:6/87=7%)
Hangbin Liu  (authored:5/87=6%)
linux-doc@vger.kernel.org (open list:DOCUMENTATION)
linux-ker...@vger.kernel.org (open list)
pavel@duo:/data/l/linux-n900$


Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[PATCH] Documentation: small fixes for LEDs, hide notes about vibration

[Pavel Machek]

Spell "LED" consistently with uppercase.

We do not want people to use LED subsystem for vibrations; there's
already support for that in input subsystem. Remove notes about
vibrations not to confuse people.

Signed-off-by: Pavel Machek <pa...@ucw.cz>


diff --git a/Documentation/leds/ledtrig-transient.txt 
b/Documentation/leds/ledtrig-transient.txt
index 3bd38b4..f412603 100644
--- a/Documentation/leds/ledtrig-transient.txt
+++ b/Documentation/leds/ledtrig-transient.txt
@@ -1,7 +1,7 @@
 LED Transient Trigger
 =
 
-The leds timer trigger does not currently have an interface to activate
+The LED timer trigger does not currently have an interface to activate
 a one shot timer. The current support allows for setting two timers, one for
 specifying how long a state to be on, and the second for how long the state
 to be off. The delay_on value specifies the time period an LED should stay
@@ -16,17 +16,11 @@ set a timer to hold a state, however when user space 
application crashes or
 goes away without deactivating the timer, the hardware will be left in that
 state permanently.
 
-As a specific example of this use-case, let's look at vibrate feature on
-phones. Vibrate function on phones is implemented using PWM pins on SoC or
-PMIC. There is a need to activate one shot timer to control the vibrate
-feature, to prevent user space crashes leaving the phone in vibrate mode
-permanently causing the battery to drain.
-
 Transient trigger addresses the need for one shot timer activation. The
-transient trigger can be enabled and disabled just like the other leds
+transient trigger can be enabled and disabled just like the other LED
 triggers.
 
-When an led class device driver registers itself, it can specify all leds
+When an LED class device driver registers itself, it can specify all LED
 triggers it supports and a default trigger. During registration, activation
 routine for the default trigger gets called. During registration of an led
 class device, the LED state does not change.
@@ -42,12 +36,12 @@ that are active at the time driver gets suspended, continue 
to run, without
 being able to actually change the LED state. Once driver is resumed, triggers
 start functioning again.
 
-LED state changes are controlled using brightness which is a common led
+LED state changes are controlled using brightness which is a common LED
 class device property. When brightness is set to 0 from user space via
 echo 0 > brightness, it will result in deactivating the current trigger.
 
 Transient trigger uses standard register and unregister interfaces. During
-trigger registration, for each led class device that specifies this trigger
+trigger registration, for each LED class device that specifies this trigger
 as its default trigger, trigger activation routine will get called. During
 registration, the LED state does not change, unless there is another trigger
 active, in which case LED state changes to LED_OFF.
@@ -56,12 +50,12 @@ During trigger unregistration, LED state gets changed to 
LED_OFF.
 
 Transient trigger activation routine doesn't change the LED state. It
 creates its properties and does its initialization. Transient trigger
-deactivation routine, will cancel any timer that is active before it cleans
+deactivation routine will cancel any timer that is active before it cleans
 up and removes the properties it created. It will restore the LED state to
 non-transient state. When driver gets suspended, irrespective of the transient
 state, the LED state changes to LED_OFF.
 
-Transient trigger can be enabled and disabled from user space on led class
+Transient trigger can be enabled and disabled from user space on LED class
 devices, that support this trigger as shown below:
 
 echo transient > trigger
@@ -144,7 +138,6 @@ repeat the following step as needed:
echo none > trigger
 
 This trigger is intended to be used for for the following example use cases:
- - Control of vibrate (phones, tablets etc.) hardware by user space app.
  - Use of LED by user space app as activity indicator.
  - Use of LED by user space app as a kind of watchdog indicator -- as
long as the app is alive, it can keep the LED illuminated, if it dies

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[PATCH] Documentation: fix little inconsistencies

[Pavel Machek]

Fix little inconsistencies in Documentation: make case and spacing
match surrounding text, fix ascii-art.

Signed-off-by: Pavel Machek <pa...@ucw.cz>

diff --git a/Documentation/filesystems/ext4.txt 
b/Documentation/filesystems/ext4.txt
index 5a8f7f4..75236c0 100644
--- a/Documentation/filesystems/ext4.txt
+++ b/Documentation/filesystems/ext4.txt
@@ -94,10 +94,10 @@ Note: More extensive information for getting started with 
ext4 can be
 * ability to pack bitmaps and inode tables into larger virtual groups via the
   flex_bg feature
 * large file support
-* Inode allocation using large virtual block groups via flex_bg
+* inode allocation using large virtual block groups via flex_bg
 * delayed allocation
 * large block (up to pagesize) support
-* efficient new ordered mode in JBD2 and ext4(avoid using buffer head to force
+* efficient new ordered mode in JBD2 and ext4 (avoid using buffer head to force
   the ordering)
 
 [1] Filesystems with a block size of 1k may see a limit imposed by the
@@ -105,7 +105,7 @@ directory hash tree having a maximum depth of two.
 
 2.2 Candidate features for future inclusion
 
-* Online defrag (patches available but not well tested)
+* online defrag (patches available but not well tested)
 * reduced mke2fs time via lazy itable initialization in conjunction with
   the uninit_bg feature (capability to do this is available in e2fsprogs
   but a kernel thread to do lazy zeroing of unused inode table blocks
@@ -602,7 +602,7 @@ Table of Ext4 specific ioctls
  bitmaps and inode table, the userspace tool thus
  just passes the new number of blocks.
 
-EXT4_IOC_SWAP_BOOT   Swap i_blocks and associated attributes
+ EXT4_IOC_SWAP_BOOT  Swap i_blocks and associated attributes
  (like i_blocks, i_size, i_flags, ...) from
  the specified inode with inode
  EXT4_BOOT_LOADER_INO (#5). This is typically
diff --git a/Documentation/networking/switchdev.txt 
b/Documentation/networking/switchdev.txt
index 5e40e1f..6309e90 100644
--- a/Documentation/networking/switchdev.txt
+++ b/Documentation/networking/switchdev.txt
@@ -29,7 +29,7 @@ with SR-IOV or soft switches, such as OVS, are possible.
   sw1p1  +  sw1p3  +  sw1p5  +  eth1
 +|+|+|+
 |||||||
- +--++++-+--++---+  +-+-+
+ +--++++++---+  +-+-+
  | Switch driver |  |mgmt   |
  |(this document)|  |   driver  |
  |   |  |   |

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH 0/3] led: ledtrig-transient: add support for hrtimer

[Pavel Machek]

On Sun 2017-04-30 14:36:58, David Lin wrote:
> Hi,
> 
> These patch series add the LED_BRIGHTNESS_FAST flag support for
> ledtrig-transient to use hrtimer so that platforms with high-resolution timer
> support can have better accuracy in the trigger duration timing. The need for
> this support is driven by the fact that Android has removed the timed_ouput 
> [1]
> and is now using led-trigger for handling vibrator control which requires the
> timer to be accurate up to a millisecond. However, this flag support would 
> also
> allow hrtimer to co-exist with the ktimer without causing warning to the
> existing drivers [2].

Yes, and objection still stands: You are misusing LED subsystem for
vibration motors. We already have support for haptic feedback in input
subsystem.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v7 3/3] x86: Make the GDT remapping read-only on 64-bit

[Pavel Machek]

On Tue 2017-03-14 10:05:08, Thomas Garnier wrote:
> This patch makes the GDT remapped pages read-only to prevent corruption.
> This change is done only on 64-bit.
> 
> The native_load_tr_desc function was adapted to correctly handle a
> read-only GDT. The LTR instruction always writes to the GDT TSS entry.
> This generates a page fault if the GDT is read-only. This change checks
> if the current GDT is a remap and swap GDTs as needed. This function was
> tested by booting multiple machines and checking hibernation works
> properly.
> 
> KVM SVM and VMX were adapted to use the writeable GDT. On VMX, the
> per-cpu variable was removed for functions to fetch the original GDT.
> Instead of reloading the previous GDT, VMX will reload the fixmap GDT as
> expected. For testing, VMs were started and restored on multiple
> configurations.
> 
> Signed-off-by: Thomas Garnier 

Can we get the same change for 32-bit, too? Growing differences
between 32 and 64 bit are a bit of a problem...
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCHv3 2/2] arch: Rename CONFIG_DEBUG_RODATA and CONFIG_DEBUG_MODULE_RONX

[Pavel Machek]

Hi!

>  
> -config DEBUG_RODATA
> +config STRICT_KERNEL_RWX
>   bool "Make kernel text and rodata read-only" if ARCH_OPTIONAL_KERNEL_RWX
>   depends on ARCH_HAS_STRICT_KERNEL_RWX
>   default !ARCH_OPTIONAL_KERNEL_RWX ||

Debug features are expected to have runtime cost, so kconfig help is
silent about those. But there are runtime costs, right? It would be
nice to mention them in the help text...

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCHv2 1/2] arch: Move CONFIG_DEBUG_RODATA and CONFIG_SET_MODULE_RONX to be common

[Pavel Machek]

On Mon 2017-02-06 10:47:45, Laura Abbott wrote:
> On 02/03/2017 01:08 PM, Kees Cook wrote:
> > On Fri, Feb 3, 2017 at 12:29 PM, Russell King - ARM Linux
> >  wrote:
> >> On Fri, Feb 03, 2017 at 11:45:56AM -0800, Kees Cook wrote:
> >>> On Fri, Feb 3, 2017 at 9:52 AM, Laura Abbott  wrote:
>  diff --git a/arch/Kconfig b/arch/Kconfig
>  index 99839c2..22ee01e 100644
>  --- a/arch/Kconfig
>  +++ b/arch/Kconfig
>  @@ -781,4 +781,32 @@ config VMAP_STACK
>    the stack to map directly to the KASAN shadow map using a 
>  formula
>    that is incorrect if the stack is in vmalloc space.
> 
>  +config ARCH_NO_STRICT_RWX_DEFAULTS
>  +   def_bool n
>  +
>  +config ARCH_HAS_STRICT_KERNEL_RWX
>  +   def_bool n
>  +
>  +config DEBUG_RODATA
>  +   def_bool y if !ARCH_NO_STRICT_RWX_DEFAULTS
>  +   prompt "Make kernel text and rodata read-only" if 
>  ARCH_NO_STRICT_RWX_DEFAULTS
> >>>
> >>> Ah! Yes, perfect. I totally forgot about using conditional "prompt"
> >>> lines. Nice!
> >>
> >> It's no different from the more usual:
> >>
> >> bool "Make kernel text and rodata read-only" if 
> >> ARCH_NO_STRICT_RWX_DEFAULTS
> >> default y if !ARCH_NO_STRICT_RWX_DEFAULTS
> >> depends on ARCH_HAS_STRICT_KERNEL_RWX
> >>
> >> But... I really don't like this - way too many negations and negatives
> >> which make it difficult to figure out what's going on here.
> >>
> >> The situation we have today is:
> >>
> >> -config DEBUG_RODATA
> >> -   bool "Make kernel text and rodata read-only"
> >> -   depends on MMU && !XIP_KERNEL
> >> -   default y if CPU_V7
> >>
> >> which is "allow the user to select DEBUG_RODATA if building a MMU non-XIP
> >> kernel", suggesting that the user turns it on for ARMv7 CPUs.
> >>
> >> That changes with this and the above:
> >>
> >> +   select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL
> >> +   select ARCH_HAS_STRICT_MODULE_RWX if MMU
> >> +   select ARCH_NO_STRICT_RWX_DEFAULTS if !CPU_V7
> >>
> >> This means that ARCH_HAS_STRICT_KERNEL_RWX is set for a MMU non-XIP
> >> kernel, which carries the same pre-condition for DEBUG_RODATA - no
> >> problem there.
> >>
> >> However, ARCH_NO_STRICT_RWX_DEFAULTS is set for non-ARMv7 CPUs, which
> >> means the "Make kernel text and rodata read-only" prompt _is_ provided
> >> for those.  However, for all ARMv7 systems, we go from "suggesting that
> >> the user enables the option" to "you don't have a choice, you get this
> >> whether you want it or not."
> >>
> >> I'd prefer to keep it off for my development systems, where I don't
> >> care about kernel security.  If we don't wish to do that as a general
> >> rule, can we make it dependent on EMBEDDED?
> >>
> >> Given that on ARM it can add up to 4MB to the kernel image - there
> >> _will_ be about 1MB before the .text section, the padding on between
> >> __modver and __ex_table which for me is around 626k, the padding
> >> between .notes and the init sections start with .vectors (the space
> >> between __ex_table and end of .notes is only 4124, which gets padded
> >> up to 1MB) and lastly the padding between the .init section and the
> >> data section (for me around 593k).  This all adds up to an increase
> >> in kernel image size of 3.2MB on 14.2MB - an increase of 22%.
> >>
> >> So no, I'm really not happy with that.
> > 
> > Ah yeah, good point. We have three cases: unsupported, mandatory,
> > optional, but we have the case of setting the default for the optional
> > case. Maybe something like this?
> > 
> > config STRICT_KERNEL_RWX
> >   bool "Make kernel text and rodata read-only" if ARCH_OPTIONAL_KERNEL_RWX
> >   depends on ARCH_HAS_STRICT_KERNEL_RWX
> >   default ARCH_OPTIONAL_KERNEL_RWX_DEFAULT
> > 
> > unsupported:
> > !ARCH_HAS_STRICT_KERNEL_RWX
> > 
> > mandatory:
> > ARCH_HAS_STRICT_KERNEL_RWX
> > !ARCH_OPTIONAL_KERNEL_RWX
> > 
> > optional:
> > ARCH_HAS_STRICT_KERNEL_RWX
> > ARCH_OPTIONAL_KERNEL_RWX
> > with default controlled by ARCH_OPTIONAL_KERNEL_RWX_DEFAULT
> > 
> > Then arm is:
> >   select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL
> >   select ARCH_HAS_STRICT_MODULE_RWX if MMU
> >   select ARCH_OPTIONAL_KERNEL_RWX if ARCH_HAS_STRICT_KERNEL_RWX
> >   select ARCH_OPTIONAL_KERNEL_RWX_DEFAULT if CPU_V7
> > 
> > x86 and arm64 are:
> >   select ARCH_HAS_STRICT_KERNEL_RWX
> >   select ARCH_HAS_STRICT_MODULE_RWX
> > 
> > ?
> > 
> > -Kees
> > 
> 
> Yes, that looks good. I wanted it to be mandatory to avoid the
> mindset of "optional means we don't need it" but I see there
> are some cases where it's better to turn it off. I'll see if
> I can emphasize this properly in the help text ("Say Y here
> unless you love security exploits running in production")

What about fixing the memory wastage, instead? If you want something
almost-always-on, it should not waste megabytes of memory.

And BTW it is help text, not 

Re: [PATCH 1/2] security: Change name of CONFIG_DEBUG_RODATA

[Pavel Machek]

On Wed 2017-01-25 12:21:05, Laura Abbott wrote:
> On 01/19/2017 08:53 AM, Pavel Machek wrote:
> >On Wed 2017-01-18 17:29:05, Laura Abbott wrote:
> >>
> >>Despite the word 'debug' in CONFIG_DEBUG_RODATA, this kernel option
> >>provides key security features that are to be expected on a modern
> >>system. Change the name to CONFIG_HARDENED_PAGE_MAPPINGS which more
> >>accurately describes what this option is intended to do.
> >
> >I think this is bad change. CONFIG_DEBUG_RODATA is describing what it
> >does, CONFIG_HARDENED_PAGE_MAPPINGS is advertising.
> >
> >We don't do advertising, and we don't force people to re-answer the
> >config questions without good reason.
> >
> >CONFIG_HARDENED_RODATA might fix the first problem, but not the second
> >one.
> >
> > Pavel
> > 
> 
> (Apologies, my SMTP was set up incorrectly so my response didn't
> actually get sent out)
> 
> CONFIG_DEBUG_RODATA isn't describing what it does though. It misses
> that this config may handle much more than just rodata. I think
> Mark Rutland's suggestion of STRICT_KERNEL_RWX might be more
> descriptive.

CONFIG_BUG=y
CONFIG_LBDAF=y
CONFIG_PM_OPP=y

..it is config option. It is not description of the feature. People
are living with that config option for a while. I'd keep it.

Maybe you can go from CONFIG_DEBUG_RODATA to CONFIG_RODATA... (but
you'll still have people re-answer config option.)


Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH 1/2] security: Change name of CONFIG_DEBUG_RODATA

[Pavel Machek]

On Wed 2017-01-18 17:29:05, Laura Abbott wrote:
> 
> Despite the word 'debug' in CONFIG_DEBUG_RODATA, this kernel option
> provides key security features that are to be expected on a modern
> system. Change the name to CONFIG_HARDENED_PAGE_MAPPINGS which more
> accurately describes what this option is intended to do.

I think this is bad change. CONFIG_DEBUG_RODATA is describing what it
does, CONFIG_HARDENED_PAGE_MAPPINGS is advertising.

We don't do advertising, and we don't force people to re-answer the
config questions without good reason.

CONFIG_HARDENED_RODATA might fix the first problem, but not the second
one.

Pavel


> Signed-off-by: Laura Abbott 
> ---
>  Documentation/DocBook/kgdb.tmpl|  8 
>  Documentation/security/self-protection.txt |  2 +-
>  arch/arm/Kconfig   |  1 +
>  arch/arm/configs/aspeed_g4_defconfig   |  2 +-
>  arch/arm/configs/aspeed_g5_defconfig   |  2 +-
>  arch/arm/include/asm/cacheflush.h  |  2 +-
>  arch/arm/kernel/patch.c|  2 +-
>  arch/arm/kernel/vmlinux.lds.S  |  8 
>  arch/arm/mm/Kconfig| 14 +-
>  arch/arm/mm/init.c |  4 ++--
>  arch/arm64/Kconfig |  4 +---
>  arch/arm64/Kconfig.debug   |  2 +-
>  arch/parisc/Kconfig|  1 +
>  arch/parisc/Kconfig.debug  | 11 ---
>  arch/parisc/configs/712_defconfig  |  2 +-
>  arch/parisc/configs/c3000_defconfig|  2 +-
>  arch/parisc/mm/init.c  |  2 +-
>  arch/s390/Kconfig  |  4 +---
>  arch/x86/Kconfig   |  4 +---
>  include/linux/init.h   |  4 ++--
>  init/main.c|  4 ++--
>  kernel/configs/android-recommended.config  |  2 +-
>  kernel/power/hibernate.c   |  2 +-
>  kernel/power/power.h   |  4 ++--
>  kernel/power/snapshot.c|  4 ++--
>  security/Kconfig   | 16 
>  26 files changed, 51 insertions(+), 62 deletions(-)
> 
> diff --git a/Documentation/DocBook/kgdb.tmpl b/Documentation/DocBook/kgdb.tmpl
> index f3abca7..a79b638 100644
> --- a/Documentation/DocBook/kgdb.tmpl
> +++ b/Documentation/DocBook/kgdb.tmpl
> @@ -115,12 +115,12 @@
>  
>  
>  If the architecture that you are using supports the kernel option
> -CONFIG_DEBUG_RODATA, you should consider turning it off.  This
> +CONFIG_HARDENED_PAGE_MAPPINGS, you should consider turning it off.  This
>  option will prevent the use of software breakpoints because it
>  marks certain regions of the kernel's memory space as read-only.
>  If kgdb supports it for the architecture you are using, you can
>  use hardware breakpoints if you desire to run with the
> -CONFIG_DEBUG_RODATA option turned on, else you need to turn off
> +CONFIG_HARDENED_PAGE_MAPPINGS option turned on, else you need to turn off
>  this option.
>  
>  
> @@ -135,7 +135,7 @@
>  Here is an example set of .config symbols to enable or
>  disable for kgdb:
>  
> -# CONFIG_DEBUG_RODATA is not set
> +# CONFIG_HARDENED_PAGE_MAPPINGS is not 
> set
>  CONFIG_FRAME_POINTER=y
>  CONFIG_KGDB=y
>  CONFIG_KGDB_SERIAL_CONSOLE=y
> @@ -166,7 +166,7 @@
>  
>  Here is an example set of .config symbols to enable/disable kdb:
>  
> -# CONFIG_DEBUG_RODATA is not set
> +# CONFIG_HARDENED_PAGE_MAPPINGS is not 
> set
>  CONFIG_FRAME_POINTER=y
>  CONFIG_KGDB=y
>  CONFIG_KGDB_SERIAL_CONSOLE=y
> diff --git a/Documentation/security/self-protection.txt 
> b/Documentation/security/self-protection.txt
> index 3010576..da8cb36 100644
> --- a/Documentation/security/self-protection.txt
> +++ b/Documentation/security/self-protection.txt
> @@ -51,7 +51,7 @@ kernel, they are implemented in a way where the memory is 
> temporarily
>  made writable during the update, and then returned to the original
>  permissions.)
>  
> -In support of this are (the poorly named) CONFIG_DEBUG_RODATA and
> +In support of this are CONFIG_HARDENED_PAGE_MAPPINGS and
>  CONFIG_DEBUG_SET_MODULE_RONX, which seek to make sure that code is not
>  writable, data is not executable, and read-only data is neither writable
>  nor executable.
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 186c4c2..09aff28 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -7,6 +7,7 @@ config ARM
>   select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
>   select ARCH_HAVE_CUSTOM_GPIO_H
>   select ARCH_HAS_GCOV_PROFILE_ALL
> + select ARCH_HAS_HARDENED_MAPPINGS if MMU && !XIP_KERNEL
>   select ARCH_MIGHT_HAVE_PC_PARPORT
>   

Re: [PATCH] doc: add note on usleep_range range

[Pavel Machek]

Hi!

> > "to have zero jitter" at least. I believe it is "does not".
> > 
> > I don't see how atomic vs. non-atomic context makes difference. There
> > are sources of jitter that affect atomic context...
> 
> The relevance is that while there is jitter in atomic context it can
> be quite small (depending on your hardware and the specifics of system
> config) but in non-atomic context the jitter is so large that it
> makes no relevant difference if you give usleep_range slack of a few
> microseconds.

I disagree here. Even in non-atomic code, you'll get _no_ jitter most
of the time. If you care about average case, small slack may still
make sense.

> > > + less than 50 microseconds probably is only preventing
> > > + timer subsystem optimization but providing no benefit.
> > 
> > And I don't trust you here. _If_ it prevents timer optimalization,
> > _then_ it provides benefit, at least in the average case.
> >
> here is the data:
> 
> System: Intel Core i7 CPU 920 @ 2.67GHz Ocotocore
> OS: Debian 8.1 (but thats quite irrelevant)
> Kernel: 4.10-rc2 (localversion-next next-20170106)
> config: x86_64_defconfig (Voluntary | Preempt)
> 
> Test-setup - poped this into akernel module and just 
> brute force load/unload it in a loop - not very elegant
> but it does the job.
> 
> static int __init usleep_test_init(void)
> {
> ktime_t now,last;
> unsigned long min,max;
> min = 200;
> max = 250;
> last = ktime_get();
> usleep_range(min, max);
> now = ktime_get();
> printk("%llu\n", ktime_to_ns(now)-ktime_to_ns(last));
> return 0;
> }
> 
> Results:
> 
> usleep_range() 5000 samples - idle system 
>  100,100 200,200 190,200
>  Min.   :188481  Min.   :201917  Min.   :197793
>  1st Qu.:207062  1st Qu.:207057  1st Qu.:207051
>  Median :207139  Median :207133  Median :207133
>  Mean   :207254  Mean   :207233  Mean   :207244
>  3rd Qu.:207341  erd Qu.:207262  3rd Qu.:207610
>  Max.   :225340  Max.   :214222  Max.   :214885
> 
> 100,200 to 200,200 is maybe relevant impact for
> some systems with respect to the outliers, but
> mean and median are almost the same, for
> 190,200 to 200,200 there is statistically no
> significant difference with respect to performance
> Note that the timestamp before and after also has
> jitter - so only part of the jitter can be attributed
> to usleep_range() it self. But idle system optimization
> is not that interesting for most systems.

I disagree here. Most of systems are idle, most of the time. You say
that basically everyone should provide 50 usec of slack... So I guess
I'd like to see comparisons for 200,200 and 200,250 (and perhaps also
200,500 or something).

Thanks,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[PATCH] regulator/overview.txt: Use ".." for ranges, instead of "->"

[Pavel Machek]

Using "->" to indicate range is not too common, switch to ".."

Signed-off-by: Pavel Machek <pa...@ucw.cz>

--- a/Documentation/power/regulator/overview.txt
+++ b/Documentation/power/regulator/overview.txt
@@ -90,7 +90,7 @@ Some terms used in this document:-
operating parameters and is specified in the regulator
datasheet. i.e.
 
- - voltage output is in the range 800mV -> 3500mV.
+ - voltage output is in the range 800mV .. 3500mV.
  - regulator current output limit is 20mA @ 5V but is
10mA @ 10V.
 
@@ -99,8 +99,8 @@ Some terms used in this document:-
power domain to a particular power range. i.e.
 
  - Domain-1 voltage is 3300mV
- - Domain-2 voltage is 1400mV -> 1600mV
- - Domain-3 current limit is 0mA -> 20mA.
+ - Domain-2 voltage is 1400mV .. 1600mV
+ - Domain-3 current limit is 0mA .. 20mA.
 
Consumer Level: This is defined by consumer drivers
dynamically setting voltage or current limit levels.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH V4] leds: trigger: Introduce an USB port trigger

[Pavel Machek]

On Wed 2016-08-31 14:23:13, Alan Stern wrote:
> On Tue, 30 Aug 2016, Rafał Miłecki wrote:
> 
> > >> As you quite often need more complex LED management, there are
> > >> triggers that were introduced in 2006 by c3bc9956ec52f ("[PATCH] LED:
> > >> add LED trigger tupport"). Some triggers are trivial and could be
> > >> implemented in userspace as well (e.g. "timer"). Some had to be
> > >> implemented in kernelspace (CPU activity, MTD activity, etc.). Having
> > >> few triggers compiled, you can assign them to LEDs at it pleases you.
> > >> Your hardware may have generic LED (not labeled) and you can
> > >> dynamically assign various triggers to it, depending e.g. on user
> > >> actions. E.g. if user (using GUI or whatever) wants to see flash
> > >> activity, your userspace script should do:
> > >> echo mtd > /sys/class/leds/foo/trigger
> > >
> > > So for example, you might want to do:
> > >
> > > echo usb1-4 >/sys/class/leds/foo/trigger
> > >
> > > and then have the "foo" LED toggle whenever an URB was submitted or
> > > completed for a device attached to the 1-4 port.  Right?
> > 
> > Not really as it won't cover some pretty common use cases. Many home
> > routers have few USB ports (2-5) and only 1 USB LED. It has to be
> > possible to assign few USB ports to a single LED (trigger). That way
> > LED should be turned on (and kept on) if there is at least 1 USB
> > device connected. You obviously can't do:
> > echo "usb1-1 usb1-2 usb2-1" > /sys/class/leds/foo/trigger
> > 
> > This was already brought up by Rob (who mentioned CPU trigger) and I
> > replied him pretty much the same way in:
> > https://lkml.org/lkml/2016/7/29/38
> > (reply starts with "Anyway, the serious limitation I see").
> 
> The code for a bunch of triggers must already be written.  What would 
> the user do if he wanted to flash a single LED in response to both
> CPU activity and MTD activity?  If not
> 
>   echo "cpu mtd" >/sys/class/leds/foo/trigger

Lets not overcomplicate this... What if user wanted to blink only when
there's both cpu and mtd activity?

I mean, there are way too many possible combinations, but we should
not implement everything. "Heartbeat" for example is nice demo and
nice test case, but ...

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH V4] leds: trigger: Introduce an USB port trigger

[Pavel Machek]

Hi!

> This commit adds a new trigger responsible for turning on LED when USB
> device gets connected to the specified USB port. This can can useful for
> various home routers that have USB port(s) and a proper LED telling user
> a device is connected.
> 
> The trigger gets its documentation file but basically it just requires
> specifying USB port in a Linux format (e.g. echo 1-1 > new_port).
> 
> During work on this trigger there was a plan to add DT bindings for it,
> but there wasn't an agreement on the format yet. This can be worked on
> later, a sysfs interface is needed anyway for platforms not using DT.
> 
> Another planned feature is support for LED reacting to the USB activity.
> This can be implemented with another sysfs file for setting mode. The
> default mode wouldn't change so there won't be ABI breakage and such
> feature can be safely implemented later.

Actually... USB device plugs/unplugs are pretty rare events... Can we
just do this in userspace using udevd?

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[PATCH] regulator/overview.txt: Use ".." for ranges, instead of "->"

[Pavel Machek]

Using "->" to indicate range is not too common, switch to ".."

Signed-off-by: Pavel Machek <pa...@ucw.cz>

--- a/Documentation/power/regulator/overview.txt
+++ b/Documentation/power/regulator/overview.txt
@@ -90,7 +90,7 @@ Some terms used in this document:-
operating parameters and is specified in the regulator
datasheet. i.e.
 
- - voltage output is in the range 800mV -> 3500mV.
+ - voltage output is in the range 800mV .. 3500mV.
  - regulator current output limit is 20mA @ 5V but is
10mA @ 10V.
 
@@ -99,8 +99,8 @@ Some terms used in this document:-
power domain to a particular power range. i.e.
 
  - Domain-1 voltage is 3300mV
- - Domain-2 voltage is 1400mV -> 1600mV
- - Domain-3 current limit is 0mA -> 20mA.
+ - Domain-2 voltage is 1400mV .. 1600mV
+ - Domain-3 current limit is 0mA .. 20mA.
 
Consumer Level: This is defined by consumer drivers
dynamically setting voltage or current limit levels.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger

[Pavel Machek]

On Mon 2016-08-29 10:21:48, Rafał Miłecki wrote:
> On 29 August 2016 at 10:05, Pavel Machek <pa...@ucw.cz> wrote:
> >> >2) Having "ports" subdir with RW files, one per each existing physical 
> >> >port
> >> >In this situation we don't need "new_port" or "remove_port". If we
> >> >want port to be observable we just do:
> >> >echo 1 > 1-1
> >> >Implementing this solution needs reading more details from USB subsystem.
> >>
> >> The situation here is clear IMO - the number of USB ports in the system
> >> can change dynamically. I'm not sure if this can be handled easily with
> >> sysfs, where we usually expose an interface for known set of settings.
> >> struct attribute arrays are usually defined statically at the compile
> >> time and filled with the variables, that are created with DEVICE_ATTR
> >> macro.
> >
> > sysfs already exposes current view of all usb devices. Just use it.
> 
> We're talking about USB ports not devices, but this is still true. You
> can find them in
> /sys/bus/usb/devices/*/*-port*
> 
> I can't see how we could use them. How could I develop sysfs interface
> in /sys/class/leds/*/ to allow userspace assigning USB ports to the
> LED trigger?

Create /sys/bus/usb/devices/*/*-port*/led_trigger file?

(Do you plan one USB trigger, or multiple ones?)
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger

[Pavel Machek]

Hi!

> >2) Having "ports" subdir with RW files, one per each existing physical port
> >In this situation we don't need "new_port" or "remove_port". If we
> >want port to be observable we just do:
> >echo 1 > 1-1
> >Implementing this solution needs reading more details from USB subsystem.
> 
> The situation here is clear IMO - the number of USB ports in the system
> can change dynamically. I'm not sure if this can be handled easily with
> sysfs, where we usually expose an interface for known set of settings.
> struct attribute arrays are usually defined statically at the compile
> time and filled with the variables, that are created with DEVICE_ATTR
> macro.

sysfs already exposes current view of all usb devices. Just use it.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger

[Pavel Machek]

On Thu 2016-08-25 20:48:04, Jacek Anaszewski wrote:
> On 08/25/2016 04:30 PM, Alan Stern wrote:
> >On Thu, 25 Aug 2016, Jacek Anaszewski wrote:
> >
> >>I'd see it as follows:
> >>
> >>#cat available_ports
> >>#1-1 1-2 2-1
> >>
> >>#echo "1-1" > new_port
> >>
> >>#cat observed_ports
> >>#1-1
> >>
> >>#echo "2-1" > new_port
> >>
> >>#cat observed_ports
> >>#1-1 2-1
> >>
> >>We've already had few discussions about the sysfs designs trying
> >>to break the one-value-per-file rule for LED class device, and
> >>there was always strong resistance against.
> >
> >This scheme has multiple values in both the available_ports and
> >observed_ports files.  :-(  Not that I have any better suggestions...
> 
> Right, I forgot to add a note here, that this follows space
> separated list pattern similarly as in case of triggers attribute.
> Of course other suggestions are welcome.
> 
> Also a description of the device connected to the port would be a nice
> feature, however I am not certain about the feasibility thereof.
> >>>
> >>>What kind of description do you mean? Where should it be used / where
> >>>should it appear?
> >>>
> >>
> >>Product name/symbol. Actually it should be USB subsystem responsibility
> >>to provide the means for querying the product name by port id, if it
> >>is possible at all.
> >
> > cat /sys/bus/usb/devices/PORT/product
> > cat /sys/bus/usb/devices/PORT/manufacturer
> >
> >These will work if there is a device registered under PORT.
> 
> I've found only idProduct and idVendor files. They indeed uniquely
> identify the device, but the numbers are not human readable.

Actually, they don't. They identify device _type_. If you have two
mice of the same type connected, they'll have same idProduct /
idVendor values.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger

[Pavel Machek]

On Thu 2016-08-25 11:04:38, Jacek Anaszewski wrote:
> On 08/25/2016 10:29 AM, Rafał Miłecki wrote:
> >On 25 August 2016 at 10:03, Jacek Anaszewski  
> >wrote:
> >>On 08/24/2016 07:52 PM, Rafał Miłecki wrote:
> >>>
> >>>From: Rafał Miłecki 
> >>>
> >>>This commit adds a new trigger responsible for turning on LED when USB
> >>>device gets connected to the specified USB port. This can can useful for
> >>>various home routers that have USB port(s) and a proper LED telling user
> >>>a device is connected.
> >>>
> >>>The trigger gets its documentation file but basically it just requires
> >>>specifying USB port in a Linux format (e.g. echo 1-1 > new_port).
> >>>
> >>>During work on this trigger there was a plan to add DT bindings for it,
> >>>but there wasn't an agreement on the format yet. This can be worked on
> >>>later, a sysfs interface is needed anyway for platforms not using DT.
> >>>
> >>>Signed-off-by: Rafał Miłecki 
> >>>---
> >>>V2: Trying to add DT support, idea postponed as it will take more time
> >>>to discuss the bindings.
> >>>V3: Fix typos in commit and Documentation (thanks Jacek!)
> >>>Use "ports" sysfs file for adding and removing USB ports (thx Jacek)
> >>>Check if there is USB device connected after adding new USB port
> >>>Fix memory leak or two
> >>>V3.5: Fix e-mail address (thanks Matthias)
> >>>  Simplify conditions in usbport_trig_notify (thx Matthias)
> >>>  Make "ports" a subdirectory with file per port, to match one value
> >>>  per file sysfs rule (thanks Greg)
> >>>  As "ports" couldn't be used for adding and removing ports anymore,
> >>>  there are now "new_port" and "remove_port". Having them makes this
> >>>  API also common with e.g. pci and usb buses.
> >>
> >>
> >>Now writing new_port with "1-1" produces a file named "1-1" in the
> >>ports directory with 000 permissions. I think that what Greg had
> >>on mind by referring to "one value per file" rule was a set of
> >>files representing ports, like "1-1 1-2 2-1", and each file should be
> >>readable/writeable.
> >>
> >>For instance "echo 1 > 1-1" would enable the trigger for the port 1-1
> >>and "echo 0 > 1-1" would disable it. The problem is that we don't know
> >>the number of required ports at compilation time and the sysfs
> >>attributes would have to be dynamically created on driver instantiation.
> >>What is more, as the USB ports can dynamically appear/disappear in the
> >>system, the files would have to be created/removed accordingly during
> >>LED class device lifetime, which is not the best design for the sysfs
> >>interface I think.

Could we add a flag to the USB port, instead? That way, USB code would
take care of creating the enable file in its own directory.

Is per-port control needed? Would just global control be sufficient?

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2] leds: trigger: Introduce an USB port trigger

[Pavel Machek]

On Mon 2016-07-18 08:55:52, Rafał Miłecki wrote:
> On 18 July 2016 at 07:53, Peter Chen  wrote:
> > On Mon, Jul 18, 2016 at 07:57:34AM +0200, Rafał Miłecki wrote:
> >> On 18 July 2016 at 07:40, Peter Chen  wrote:
> >> > On Mon, Jul 18, 2016 at 06:44:49AM +0200, Rafał Miłecki wrote:
> >> >> On 18 July 2016 at 04:31, Peter Chen  wrote:
> >> >> > On Fri, Jul 15, 2016 at 11:10:45PM +0200, Rafał Miłecki wrote:
> >> >> >> +
> >> >> >> +usbport trigger:
> >> >> >> +- usb-ports : List of USB ports that usbport should observed for 
> >> >> >> turning on a
> >> >> >> +   given LED.
> >> >> >> +
> >> >> >
> >> >> > %s/should/should be
> >> >>
> >> >> Thanks.
> >> >>
> >> >>
> >> >> >> diff --git a/drivers/leds/trigger/ledtrig-usbport.c 
> >> >> >> b/drivers/leds/trigger/ledtrig-usbport.c
> >> >> >> new file mode 100644
> >> >> >> index 000..97b064c
> >> >> >> --- /dev/null
> >> >> >> +++ b/drivers/leds/trigger/ledtrig-usbport.c
> >> >> >> @@ -0,0 +1,206 @@
> >> >> >> +/*
> >> >> >> + * USB port LED trigger
> >> >> >> + *
> >> >> >> + * Copyright (C) 2016 Rafał Miłecki 
> >> >> >> + *
> >> >> >> + * This program is free software; you can redistribute it and/or 
> >> >> >> modify
> >> >> >> + * it under the terms of the GNU General Public License as 
> >> >> >> published by
> >> >> >> + * the Free Software Foundation; either version 2 of the License, 
> >> >> >> or (at
> >> >> >> + * your option) any later version.
> >> >> >> + */
> >> >> >
> >
> > In your COPYRIGHT, it says "or any later version". But afaik, It should
> > not be on GPL v3.
> 
> If one picks my code, modifies it, relicenses it using GPL v3, we
> can't include it anymore. It's the same story as with BSD systems and
> their BSD licenses. If one picks e.g. BSD 3-clause licensed code,
> makes it GPL, releases it (e.g. by putting in Linux), BSD can't use it
> anymore.
> 
> Still, this license is GPL v2 compatible and as is it can be included
> in the Linux.

Anything GPLv2 compatible is fair game for the kernel. GPLv2+ is very
common for the kernel.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2] leds: trigger: Introduce an USB port trigger

[Pavel Machek]

Hi!

> > @@ -0,0 +1,206 @@
> > +/*
> > + * USB port LED trigger
> > + *
> > + * Copyright (C) 2016 Rafał Miłecki 
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or (at
> > + * your option) any later version.
> > + */
> 
> GPL v2 only.

No, you are not going to tell people which license they can use for
their kernel code.

GPL v2+ is perfectly fine for the kernel.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND PATCH 1/3] rfkill: Create "rfkill-airplane-mode" LED trigger

[Pavel Machek]

On Mon 2016-06-13 17:10:02, João Paulo Rechi Vita wrote:
> On 13 June 2016 at 17:01, Pavel Machek <pa...@ucw.cz> wrote:
> > On Mon 2016-06-13 15:59:35, João Paulo Rechi Vita wrote:
> >> On 13 June 2016 at 15:00, Pavel Machek <pa...@ucw.cz> wrote:
> >> > Hi!
> >> >
> >> >> > João, that means you should send a patch to add the ::rfkill suffix.
> >> >> >
> >> >>
> >> >> IMO "airplane" (or maybe "airplane-mode") is a better suffix, as it
> >> >> reflects the label on the machine's chassis. I'll name it
> >> >> "asus-wireless::airplane" and send this through platform-drivers-x86,
> >> >> as this is now contained in the platform-drivers-x86 subsystem. Thanks
> >> >> Johannes for your patience and help designing and reviewing the rfkill
> >> >> changes, even if not all of them made it through in the end. And
> >> >> thanks everyone else involved for the feedback.
> >> >
> >> > Actually, I'd do '::rfkill', for consistency with other places in
> >> > /sys.
> >> >
> >> > /sys/devices/platform/thinkpad_acpi/rfkill/rfkill1/name
> >> > /sys/class/rfkill
> >> > /sys/module/rfkill
> >> >
> >>
> >> If we use "rfkill" as a suffix, how do you expect userspace to be able
> >> to differentiate between a LED that indicates airplane-mode (LED ON
> >> when all radios are OFF) and a LED that indicates the state of a
> >> specific radio like WiFi or Bluetooth (LED ON when that specific radio
> >> is ON)? If we're going this route we should provide meaningful
> >> information here.
> >
> > '::airplane' has same problem, no?
> >
> 
> No, because in this case we would not use "airplane" as a suffix for a
> LED associated with an individual radio.
> 
> > If you want to distinguish that, maybe you can do '::rfkill' for
> > everything vs '::rfkill-wifi' for wifi-only and '::rfkill-bt' for
> > bluetooth...
> >
> 
> The problem here is that the "rfkill" name is already associated with
> individual rfkill switches under /sys/class/rfkill,
> /sys/devices/platform/*/rfkill etc, so I think we're better off
> distinguishing "airplane" vs "wifi" vs "bluetooth" etc, to avoid
> confusion.

(Actually, "::wifi" is super confusing, I'd expect that to be a led
that blinks when wifi is active.)

Well... "airplane" is quite confusing. I'd we use "rfkill" for
disabling radios, and I believe we should stick with that.

But small problem might be polarity. You may need both "::rfkill" and
"::not-rfkill".

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND PATCH 1/3] rfkill: Create "rfkill-airplane-mode" LED trigger

[Pavel Machek]

Hi!

> > João, that means you should send a patch to add the ::rfkill suffix.
> >
> 
> IMO "airplane" (or maybe "airplane-mode") is a better suffix, as it
> reflects the label on the machine's chassis. I'll name it
> "asus-wireless::airplane" and send this through platform-drivers-x86,
> as this is now contained in the platform-drivers-x86 subsystem. Thanks
> Johannes for your patience and help designing and reviewing the rfkill
> changes, even if not all of them made it through in the end. And
> thanks everyone else involved for the feedback.

Actually, I'd do '::rfkill', for consistency with other places in
/sys.

/sys/devices/platform/thinkpad_acpi/rfkill/rfkill1/name
/sys/class/rfkill
/sys/module/rfkill

Thanks for patience,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] usb: configfs: allow UDC binding rule configured as binding to *any* UDC

[Pavel Machek]

On Tue 2016-05-03 11:04:24, changbin...@intel.com wrote:
> From: "Du, Changbin" 
> 
> On most platforms, there is only one device controller available.
> In this case, we desn't care the UDC's name. So let's ignore the
> name by setting 'UDC' to 'any'. And also we can change UDC name
> at any time if it is not binded (no need set to "" first).

making "any" special does not look like a good idea. What if it really
is "any"?

Return nothing instead, not even \n?

> Signed-off-by: Du, Changbin 
> Signed-off-by: Du, Changbin 

I don't think this is how you should sign it off.

Best regards,

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/6] Intel Secure Guard Extensions

[Pavel Machek]

On Fri 2016-05-06 01:52:04, Jarkko Sakkinen wrote:
> On Mon, May 02, 2016 at 11:37:52AM -0400, Austin S. Hemmelgarn wrote:
> > On 2016-04-29 16:17, Jarkko Sakkinen wrote:
> > >On Tue, Apr 26, 2016 at 09:00:10PM +0200, Pavel Machek wrote:
> > >>On Mon 2016-04-25 20:34:07, Jarkko Sakkinen wrote:
> > >>>Intel(R) SGX is a set of CPU instructions that can be used by
> > >>>applications to set aside private regions of code and data.  The code
> > >>>outside the enclave is disallowed to access the memory inside the
> > >>>enclave by the CPU access control.
> > >>>
> > >>>The firmware uses PRMRR registers to reserve an area of physical memory
> > >>>called Enclave Page Cache (EPC). There is a hardware unit in the
> > >>>processor called Memory Encryption Engine. The MEE encrypts and decrypts
> > >>>the EPC pages as they enter and leave the processor package.
> > >>
> > >>What are non-evil use cases for this?
> > >
> > >I'm not sure what you mean by non-evil.
> > >
> > I would think that this should be pretty straightforward.  Pretty much every
> > security technology integrated in every computer in existence has the
> > potential to be used by malware for various purposes.  Based on a cursory
> > look at SGX, it is pretty easy to figure out how to use this to hide
> > arbitrary code from virus scanners and the OS itself unless you have some
> > way to force everything to be a debug enclave, which entirely defeats the
> > stated purpose of the extensions.  I can see this being useful for tight
> > embedded systems.  On a desktop which I have full control of physical access
> > to though, it's something I'd immediately turn off, because the risk of
> > misuse is so significant (I've done so on my new Thinkpad L560 too, although
> > that's mostly because Linux doesn't support it yet).
> 
> The code in enclave binary is in clear text so it does not really
> allow you to completely hide any code. It's a signed binary, not
> encypted binary.

Umm. Now you are evil.

Yes, the code that starts in the enclave may not be encrypted, but I'm
pretty sure the enclave will download some more code from remote
server after attestation... x86 or some kind of interpretted code.

(But of course we already know that the technology is evil, as only
Intel can use it, see Ingo's reply.)
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/6] Intel Secure Guard Extensions

[Pavel Machek]

Hi!

> Good morning, I hope everyone's day is starting out well.

:-). Rainy day here.

> > > In the TL;DR department I would highly recommend that anyone
> > > interested in all of this read MIT's 170+ page review of the
> > > technology before jumping to any conclusions :-)
> 
> > Would you have links for 1-5?
> 
> First off my apologies to the list as I loathe personal inaccuracy,
> the MIT review paper is only 117 pages long.  I was typing the last
> e-mail at 0405 in the morning and was scrambling for the opportunity
> to get 50 minutes of sleep so my proofreading was sloppy... :-)

Thanks a lot for the links, I'd still say it was more accurate than
average for the lkml.

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND PATCH 1/3] rfkill: Create "rfkill-airplane-mode" LED trigger

[Pavel Machek]

Hi!

> This creates a new LED trigger to be used by platform drivers as a
> default trigger for airplane-mode indicator LEDs.
> 
> By default this trigger will fire when RFKILL_OP_CHANGE_ALL is called
> for all types (RFKILL_TYPE_ALL), setting the LED brightness to LED_FULL
> when the changing the state to blocked, and to LED_OFF when the changing
> the state to unblocked. In the future there will be a mechanism for
> userspace to override the default policy, so it can implement its
> own.

If userspace wants to control the manually, it can do just that --
control it manually. There should not be a need to "override the
default policy".
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v1 02/18] x86: Secure Memory Encryption (SME) build enablement

[Pavel Machek]

On Wed 2016-04-27 17:41:40, Borislav Petkov wrote:
> On Wed, Apr 27, 2016 at 05:30:10PM +0200, Pavel Machek wrote:
> > Doing it early will break bisect, right?
> 
> How exactly? Please do tell.

Hey look, SME slowed down 30% since being initially merged into
kernel!
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v1 00/18] x86: Secure Memory Encryption (AMD)

[Pavel Machek]

On Wed 2016-04-27 16:05:20, Borislav Petkov wrote:
> On Tue, Mar 22, 2016 at 02:00:58PM +0100, Pavel Machek wrote:
> > Why would I want SME on my system? My system seems to work without it.
> 
> Your system doesn't have it and SME is default off.

That does not answer the question. "Why would I want SME on my
system?".

And that answer should go to Documentation/.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v1 03/18] x86: Secure Memory Encryption (SME) support

[Pavel Machek]

On Tue 2016-04-26 17:56:26, Tom Lendacky wrote:
> Provide support for Secure Memory Encryption (SME). This initial support
> defines the memory encryption mask as a variable for quick access and an
> accessor for retrieving the number of physical addressing bits lost if
> SME is enabled.
> 
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/include/asm/mem_encrypt.h |   37 
> 
>  arch/x86/kernel/Makefile   |2 ++
>  arch/x86/kernel/mem_encrypt.S  |   29 
>  arch/x86/kernel/x8664_ksyms_64.c   |6 ++
>  4 files changed, 74 insertions(+)
>  create mode 100644 arch/x86/include/asm/mem_encrypt.h
>  create mode 100644 arch/x86/kernel/mem_encrypt.S
> 
> index 000..ef7f325
> --- /dev/null
> +++ b/arch/x86/kernel/mem_encrypt.S
> @@ -0,0 +1,29 @@
> +/*
> + * AMD Memory Encryption Support
> + *
> + * Copyright (C) 2016 Advanced Micro Devices, Inc.
> + *
> + * Author: Tom Lendacky 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +
> + .text
> + .code64
> +ENTRY(sme_get_me_loss)
> + xor %rax, %rax
> + mov sme_me_loss(%rip), %al
> + ret
> +ENDPROC(sme_get_me_loss)

Does this really need to be implemented in assembly?


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v1 02/18] x86: Secure Memory Encryption (SME) build enablement

[Pavel Machek]

On Tue 2016-04-26 17:56:14, Tom Lendacky wrote:
> Provide the Kconfig support to build the SME support in the kernel.


Probably should go last in the series?

> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/Kconfig |9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 7bb1574..13249b5 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1356,6 +1356,15 @@ config X86_DIRECT_GBPAGES
> supports them), so don't confuse the user by printing
> that we have them enabled.
>  
> +config AMD_MEM_ENCRYPT
> + bool "Secure Memory Encryption support for AMD"
> + depends on X86_64 && CPU_SUP_AMD
> + ---help---
> +   Say yes to enable the encryption of system memory. This requires
> +   an AMD processor that supports Secure Memory Encryption (SME).
> +   The encryption of system memory is disabled by default but can be
> +   enabled with the mem_encrypt=on command line option.
> +
>  # Common NUMA Features
>  config NUMA
>   bool "Numa Memory Allocation and Scheduler Support"

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v1 00/18] x86: Secure Memory Encryption (AMD)

[Pavel Machek]

Hi!

> This RFC patch series provides support for AMD's new Secure Memory
> Encryption (SME) feature.
> 
> SME can be used to mark individual pages of memory as encrypted through the
> page tables. A page of memory that is marked encrypted will be automatically
> decrypted when read from DRAM and will be automatically encrypted when
> written to DRAM. Details on SME can found in the links below.

Well, actually brief summary should go to changelog and probably to the 
documentation,
too...

Why would I want SME on my system? My system seems to work without it.

Does it protect against cold boot attacks? Rowhammer (I guess not?)

Does it cost some performance?

Does it break debugging over JTAG?

> The approach that this patch series takes is to encrypt everything possible
> starting early in the boot where the kernel is encrypted. Using the page
> table macros the encryption mask can be incorporated into all page table
> entries and page allocations. By updating the protection map, userspace
> allocations are also marked encrypted. Certain data must be accounted for
> as having been placed in memory before SME was enabled (EFI, initrd, etc.)
> and accessed accordingly.

Do you also need to do something special for device DMA?

Thanks,

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/6] Intel Secure Guard Extensions

[Pavel Machek]

Hi!

> > > Preventing cold boot attacks is really just icing on the cake.  The
> > > real point of this is to allow you to run an "enclave".  An SGX
> > > enclave has unencrypted code but gets access to a key that only it can
> > > access.  It could use that key to unwrap your ssh private key and sign
> > > with it without ever revealing the unwrapped key.  No one, not even
> > > root, can read enclave memory once the enclave is initialized and gets
> > > access to its personalized key.  The point of the memory encryption
> > > engine to to prevent even cold boot attacks from being used to read
> > > enclave memory.
> >
> > Ok, so the attacker can still access the "other" machine, but ok, key
> > is protected.
> >
> > But... that will mean that my ssh will need to be SGX-aware, and that
> > I will not be able to switch to AMD machine in future. ... or to other
> > Intel machine for that matter, right?
> 
> That's the whole point.  You could keep an unwrapped copy of the key
> offline so you could provision another machine if needed.
> 
> >
> > What new syscalls would be needed for ssh to get all this support?
> 
> This patchset or similar, plus some user code and an enclave to use.
> 
> Sadly, on current CPUs, you also need Intel to bless the enclave.  It
> looks like new CPUs might relax that requirement.

Umm. I'm afraid my evil meter just went over "smells evil" and "bit
evil" areas straight to "certainly looks evil".

> > > Replay Protected Memory Block.  It's a device that allows someone to
> > > write to it and confirm that the write happened and the old contents
> > > is no longer available.  You could use it to implement an enclave that
> > > checks a password for your disk but only allows you to try a certain
> > > number of times.
> >
> > Ookay... I guess I can get a fake Replay Protected Memory block, which
> > will confirm that write happened and not do anything from China, but
> > ok, if you put that memory on the CPU, you raise the bar to a "rather
> > difficult" (tm) level. Nice.
> 
> It's not so easy for the RPMB to leak things.  It would be much easier
> for it to simply not provide replay protection (i.e. more or less what
> the FBI asked from Apple: keep allowing guesses even though that
> shouldn't work).

Yup.

> > But that also means that when my CPU dies, I'll no longer be able to
> > access the encrypted data.
> 
> You could implement your own escrow policy and keep a copy in the
> safe.

And then Intel would have to bless my own escrow policy, which is,
realistically, not going to happen, right?

> > And, again, it means that quite complex new kernel-user interface will
> > be needed, right?
> 
> It's actually fairly straightforward, and the kernel part doesn't care
> what you use it for (the kernel part is the same for disk encryption
> and ssh, for example, except that disk encryption would care about
> replay protection, whereas ssh wouldn't).

So we end up with parts of kernel we can not change, and where we may
not even change the compiler. That means assembly. Hey, user, you have
freedom to this code, except it will not work. That was called TiVo
before. We'd have security-relevant parts of kernel where we could not
even fix a securit holes without Intel.

If anything, this is reason to switch to GPLv3.

I'm sorry. This is evil.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/6] Intel Secure Guard Extensions

[Pavel Machek]

On Tue 2016-04-26 21:59:52, One Thousand Gnomes wrote:
> > But... that will mean that my ssh will need to be SGX-aware, and that
> > I will not be able to switch to AMD machine in future. ... or to other
> > Intel machine for that matter, right?
> 
> I'm not privy to AMD's CPU design plans.
> 
> However I think for the ssl/ssh case you'd use the same interfaces
> currently available for plugging in TPMs and dongles. It's a solved
> problem in the crypto libraries.
> 
> > What new syscalls would be needed for ssh to get all this support?
> 
> I don't see why you'd need new syscalls.

So the kernel will implement few selected crypto algorithms, similar
to what TPM would provide, using SGX, and then userspace no longer
needs to know about SGX?

Ok, I guess that's simple.

It also means it is boring, and the multiuser-game-of-the-day will not
be able to protect the (plain text) password from the cold boot
attack.

Nor will be emacs be able to protect in-memory copy of my diary from
cold boot attack.

So I guess yes, some new syscalls would be nice :-).
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] kaslr: allow kASLR to be default over Hibernation

[Pavel Machek]

On Thu 2016-04-14 13:14:07, Kees Cook wrote:
> On Thu, Apr 14, 2016 at 1:01 PM, Pavel Machek <pa...@denx.de> wrote:
> > Hi!
> >
> >> Since kASLR and Hibernation can not currently coexist at runtime
> >> on x86, the default behavior was to disable kASLR by default when
> >> CONFIG_HIBERNATION was present (to retain original behavior).
> >>
> >> The behavior of kASLR on arm64 (and soon MIPS) is to be enabled by
> >> default when selected at build time. Since arm64 Hibernation does not
> >> conflict with kASLR, this fixes the hibernation argument parsing to be
> >> x86-specific. Additionally, since end users want to be able to select
> >> kASLR on x86 by default at build time, create CONFIG_RANDOMIZE_BASE_ON
> >> that is present only on x86.
> >>
> >> Signed-off-by: Kees Cook <keesc...@chromium.org>
> >
> > I believe this is bad idea. arm64 shows that kaslr and hibernation can
> > coexist, and hibernation is still useful when your battery runs out.
> 
> What? I'm confused -- this patch leaves the x86 behavior as-is by
> default but allows hibernation to work with arm64. (For example, right
> now, if you boot arm64 with "kaslr" kernel argument, hibernation will
> get needlessly disabled.)

So it is very different from the PATCH v1, still it shares the
subject?

This is the part I don't like:

> >> Since kASLR and Hibernation can not currently coexist at runtime
> >> on x86, the default behavior was to disable kASLR by default when
> >> CONFIG_HIBERNATION was present (to retain original behavior).

Now I notice that it is quite unclear if it actually changes
anything...

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] kaslr: allow kASLR to be default over Hibernation

[Pavel Machek]

Hi!

> Since kASLR and Hibernation can not currently coexist at runtime
> on x86, the default behavior was to disable kASLR by default when
> CONFIG_HIBERNATION was present (to retain original behavior).
> 
> The behavior of kASLR on arm64 (and soon MIPS) is to be enabled by
> default when selected at build time. Since arm64 Hibernation does not
> conflict with kASLR, this fixes the hibernation argument parsing to be
> x86-specific. Additionally, since end users want to be able to select
> kASLR on x86 by default at build time, create CONFIG_RANDOMIZE_BASE_ON
> that is present only on x86.
> 
> Signed-off-by: Kees Cook 

I believe this is bad idea. arm64 shows that kaslr and hibernation can
coexist, and hibernation is still useful when your battery runs out.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Prefer kASLR over Hibernation

[Pavel Machek]

Hi!

> When building with both CONFIG_HIBERNATION and CONFIG_RANDOMIZE_BASE,
> one or the other must be chosen at boot-time. Until now, hibernation
> was selected when no choice was made on the command line.
> 
> To make the security benefits of kASLR more widely available to end
> users (since the use of hibernation is becoming more rare and kASLR,
> already available on x86, will be available on arm64 and MIPS soon),
> this changes the default to preferring kASLR over hibernation. Users
> wanting hibernation can turn off kASLR by adding "nokaslr" to the kernel
> command line.

I must say I don't exactly like this patch.

Why is kASLR incompatible with hibernation? We can hibernate have 
4.3 kernel resume hibernation image of 4.2 kernel (on x86-64, and I
have patches for x86). Resuming kernel with different randomization
does not look that much different...

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: custom ioctl-based interface to control LED in networking (was Re: [PATCHv2 09/10] rfkill: Userspace control for airplane mode)

[Pavel Machek]

On Wed 2016-02-24 12:01:37, Johannes Berg wrote:
> On Wed, 2016-02-24 at 11:46 +0100, Pavel Machek wrote:
> 
> > If you want different trigger, implement different trigger. If you
> > want to indicate all but wifi, implement all but wifi, and then
> > userspace can select it by writing trigger name. 
> 
> This is still mostly a strawman, since userspace cannot have a database
> of LEDs that indicate airplane mode.

Why would it need to? It could look at default triggers for the led if
it really wanted to.

> I'm sure you'd also not like to see 2**7 triggers implemented in rfkill
> to cover all the possibilities.

Are all the possibilities useful? I assumed about 2 are. If you need
2**7 of them, LED triggers can have parameters.

> > If you want complete
> > userspace control, fine, but we have standard interface and it is not
> > ioctl.
> 
> The "standard interface" is usable if you really just want to driver a
> single LED and you know which one.
> 
> I think you're looking at this the wrong way, focusing too much on the
> LED aspect.
> 
> Really what you have here is a concept of "airplane mode", and that
> concept is specific to the rfkill subsystem. This happens to affect
> mostly an LED trigger, today, but as a concept it's something that
> *should* be managed within the rfkill subsystem.

How is that concept used outside the LEDs? What semantics does
"airplane mode" have? You tried to explain "airplane mode" is not well
defined up in this thread...

> > Besides, the series really should have been Cc-ed to LED
> > people, too.
> 
> That's simply unreasonable, you're essentially saying that any user of
> any kernel infrastructure should be Cc'ed to the implementer of that
> infrastructure... 9/10 patches in this series aren't even LED
> > specific,

I'm not saying that. I'm saying that LED maintainers should be Cced,
to keep the interfaces consistent.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 09/10] rfkill: Userspace control for airplane mode

[Pavel Machek]

On Tue 2016-02-23 21:55:14, Johannes Berg wrote:
> On Tue, 2016-02-23 at 21:45 +0100, Pavel Machek wrote:
> 
> > So... you add LED trigger to display the state of the airplane
> > mode. Ok, why not.
> 
> Yes. However, consider that "the airplane mode" isn't a well-defined
> concept; some systems may want to light up that LED even when wifi is
> still enabled, since you're nowadays quite likely to be allowed to use
> wifi (but not enable e.g. LTE) while in-flight.

Well "the airplane mode" is well defined. It means no intentional
transmitting at radio frequencies.

The fact that you are allowed to use WIFI on certain flights does not
change anything.

> > But now you add an way to override it? Why? If someone wants to
> > change
> > the led state, he can just change trigger to none, and then control
> > the LED manually...
> 
> Yes, but now you've forced every application that wants to deal with
> this to know about every single LED that might be used with this
> trigger... that won't work for some generic userland tool that might
> want to implement an "airplane-mode policy".

I see that "airplane mode" trigger might be a tiny bit
useful... dunno, for a LED near the airplane mode switch, when vendor
replaced hardware toggle with a key. But policy should have nothing to
do with that. If you argue additional "policy daemon" is needed for
that... forget it, that's overdesigned.

(Besides, finding all LEDs with given trigger is trivial
operation. Besides... there should never be more than one).

> > BTW what happens when the device contains both radios controlled by
> > kernel (wifi, bluetooth) and radios controlled by userspace (GSM
> > modem)?
> 
> You'd better have the userspace to control the LED :)

Yes, so lets forget that and no additional triggers? Good ;-).
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html